# PaynetEasy Documentation (full)

## Integration Documentation

### General Introduction

#### Payment Gateway overview

“Payneteasy Payment Gateway” (here and hereafter System, Payment Gateway or Payneteasy) 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:

| 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](https://doc.payneteasy.com/integration/reference/glossary.html.md).

The Payment Gateway API is also published as a machine-readable
[OpenAPI 3.1 specification](https://doc.payneteasy.com/integration/openapi.html.html.md) — use it to explore the API
interactively in your browser, generate client SDKs, or integrate with
AI coding assistants. See the OpenAPI Specification page for details.

#### 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](https://doc.payneteasy.com/integration/api_use_cases_index.html.md) section, and each API Use-Case provides clear instructions which [API commands](https://doc.payneteasy.com/integration/API_commands_index.html.md) to call on each stage of the payment flow and how to handle their results. All APIs are [asynchronous](https://doc.payneteasy.com/integration/general_api_usage/async_response.html.md). [Common utilities](https://doc.payneteasy.com/integration/common_utilities_index.html.md) section provides added value services which might be enabled by request. [FAQ](https://doc.payneteasy.com/integration/reference/faq.html.md) page helps to resolve common issues during Connecting Party integration.

Payneteasy 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 Payneteasy. 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. Merchant login.
3. Merchant control key.
4. Integration scenario documentation.

```plantuml
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 (Merchant)" #e1d5e7;line:black;line.dotted

"Connecting Party\n (Merchant)" -left-> "Endpoint\nGroup"
"Connecting Party\n (Merchant)" -down-> "layoutHelper3"
"Connecting Party\n (Merchant)" -down-> "Endpoint\n currency C"
"Connecting Party\n (Merchant)" -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 (Merchant)" -left[hidden]- "layoutHelper1"
"Connecting Party\n (Merchant)" -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](https://doc.payneteasy.com/integration/api_use_cases/sale_form.html.md) - integrate hosted payment form processing of E-commerce sale transactions.
2. [Return transactions](https://doc.payneteasy.com/integration/api_use_cases/return_transaction.html.md) - integrate processing of refunds.
3. [Connecting Party callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md) - receive transaction data to CRM, BI and other systems.
4. [Forms customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) - brand hosted payment forms and provide them to Payneteasy support manager for installation.
5. Test the solution on sandbox with Payneteasy [test scenarios](https://doc.payneteasy.com/integration/general_api_usage/test_scenarios.html.md).
6. Inform Payneteasy 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. Payneteasy 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.

transfer - Master Card Money Send, Visa Money Transfer, and Deposit-to-Card transactions.

payout - Payout is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) banking account or digital wallet. Payout transaction in most cases is used for bank account funding.

**Dispute and Service transactions:**

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).

account_verification - Zero Dollar Value Authorization Request (CVV check).

pan_eligibility - Verification request to ensure that a cardholder’s account is eligible to receive Master Card Money Send transactions. Provides additional information for sending and receiving cards: the Interbank Card Association (ICA) code of the issuer, currency code (alpha and numeric), country code (alpha and numeric), brand acceptance code, and brand product code.

### 3DS Overview

#### Payneteasy 3DS Flow

Reference:

[EMV® 3-D Secure Protocol and Core Functions Specification](https://www.emvco.com/emv-technologies/3d-secure/)

3-D Secure is a protocol designed to be an additional security layer for online credit and debit card transactions.
 
3-D Secure protocol has two main versions.
 
1.0 – which was introduced in 2001 and is still used by some acquirers (Services based on this protocol were adopted by different card schemes giving it different names: Verified by Visa or Visa Secure used by Visa, Secure Code used by Mastercard, Protect By used by Discover, J/Secure used by JCB International, American Express Safe Key used by American Express.
 
2. X – which was introduced in 2016 to strengthen and supersede the version 1.0 and it was aimed at complying with the new EU authentication requirements and resolving some short-comings of the original protocol.
 

Despite low level message exchange differences in the essence protocol version 2. X differs from 1.0 by introducing and option for the issuer of the card to perform an automatic risk assessment based on the additional contextual data sent from the payer browser or mobile app, whereas 1.0 version always requires payer to pass an authentication challenge. Correspondingly (and according to EMVCo spec) protocol version 2. X includes Frictionless flow (gathering contextual data and performing risk assessment) and Challenge flow (passing authentication challenge). The normal Payer’s web flow which passes 3DS 2. X Authentication can be illustrated as below.

1. Payers fill out a payment form provided by Connection Party or Payment Gateway side and sends data.

 

> **Note:** For Transfer transactions, payment form might look as described below.

 
1. Contextual data is gathered and sent to the Issuer in a hidden process within the browser (Frictionless flow).

 
1. If Issuer finds the transaction risky Payer’s browser gets redirected to the Issuer web page to pass authentication challenge (Challenge flow).

 
1. When Payer passes checks the payment authorization is made saving the details related to the 3DS Authentication on the acquirer side.

 
1. Payer’s browser gets redirected to the Connecting Party website to the resultant page.

 

Due to the fact that both protocol versions still used the Connecting party have to deal with both of them as well as specific integrations when acquirer handles 3D Secure communication on its end. For this purpose, Payment Gateway provides universal/generic approach based on the API commands which allow the Connecting party to handle all mentioned cases. The Connecting Party has to start with the 3DS Decision Making Schema of the relevant Use-Case which in turn refers to the more detailed diagram describing specifics of the data handling and Payer’s browser redirects related to the corresponding 3DS flow.

#### 3DS Implementation Scenarios

| Implementation Scenario | Instructions |
|------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 3DS is not initiated (non3D). | 3DS Authentication is not initiated. Follow 3DS Decision Making Schema of relevant Use-Case and implement Non3D Flow. |
| 3DS is initiated and performed by Connecting Party (for PSPs and Acquirers). | 3DS Authentication is initiated and performed by Connecting Party, results are uploaded to Payment Gateway in initial request. Follow 3DS Decision Making Schema of relevant Use-Case and implement Non3D Flow (3DS is performed before the initial request to Payment Gateway). |
| 3DS is initiated by Payment Gateway and performed on Connecting Party side. | 3DS Authentication is initiated by Payment Gateway. For 3DS 1.0.2, Payer Authentication is performed on Connecting Party side, results are uploaded to Payment Gateway. For 3DS 2.x, 3DS Method and Challenge are performed on Connecting Party side, results are uploaded to Payment Gateway. Additional fields for 3DS Method can be provided by Connecting Party in initial request to speed up the process for 3DS 2.x (tds_status=Method Url Frame will be skipped if 3DS Method is not supported by ACS). Follow 3DS Decision Making Schema of relevant Use-Case and implement all 3DS Flows. |
| 3DS is initiated and performed by Payment Gateway. | 3DS Authentication is initiated by Payment Gateway, all 3DS scenarios are performed on Payment Gateway side. Follow 3DS Decision Making Schema of relevant Use-Case, implement Simplified Authentication Flow (ignore tds_status parameter presence, use html or redirect-to parameters to redirect the Payer to Payment Gateway) and Non3D Flow (if Payer’s card is not enrolled or processing is Non3D). |

#### 3DS Decision Making Schema

```plantuml
@startuml

title 3DS Decision Making Schema
start
: (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
if ((3) **tds_status** field is present) then (YES)
if ((4) **tds_status** == MethodUrlFrame?) then (YES)
#Plum :(5) Create iframe\nto pass 3DS Method\n3DS 2.x Frictionless flow\nto be applied.\n\nSee 3DS 2.x Frictionless Flow;
(NO      ) elseif ((6) **tds_status** == CReqForm?) then (YES)
#Plum :(7) Create CReq HTML Page\nwhich redirects to ACS\n3DS 2.x Challenge Flow\nto be applied\n\nSee 3DS 2.X Challenge Flow;
(NO      ) elseif ((8) **tds_status** == PaReqForm?) then (YES)
#Plum :(9) Create PaReq HTML Page\nwhich redirects to ACS\n3DS 1.0.2 Authentication Flow\nto be applied\n\nSee 3DS 1.0.2 Authentication Flow;
endif
(NO      )elseif ((10) **html** field is present) then (YES)
#Plum :(11) Return content of the\n**html** field to the Payeras is \n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
else (NO)
endif
backward:(12) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
endwhile (YES)
:(13) Show result page to the Payer;
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
|<#Plum>| Connecting and other party |
| | Other Party |
endlegend
@enduml
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(5) If tds_status is Method Url Frame see [Frictionless 3DS 2.x](#ds-2x-frictionless-flow-overview).
 
(7) If tds_status is CReq Form see [3DS 2. X Challenge](#ds-2x-challenge-flow-overview).
 
(9) If tds_status is Pa Req Form see [3DS 1.0.2 Authentication](#ds-102-authentication-flow-overview).
 
(11) If tds status is not present, but html field is present, see [Simplified authentication](#simplified-authentication-flow-overview).
 
(12) The same as point (1).
 

##### Non3D Flow

Transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. steps 1-2-(12)-13 of [3DS decision making schema](#ds-decision-making-scheme-overview) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### 3DS 2.x.0 Frictionless Flow

```plantuml

title 3DS 2.x.0 Frictionless Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**tds-method-url-frame-3ds-server-trans-id**
**tds-method-url-frame-3ds-method-url**;
if ((3) **tds-method-url-frame-3ds-method-url** is present) then (yes)
    #Turquoise:(4) The Connecting Party constructs **3DS Method HTML Page**\ncontaining hidden iframe and upload **3DS Method Result HTML Form**\nusing the parameters received on the previous steps\nand providing **threeDSMethodNotificationURL**;
    #Turquoise:(5) HTML Page, once rendered, is automatically submitted
    into iframe (using HTML Page target attribute);
    fork
        note left
        **iframe** lifecycle
        end note
        :(6) Payer's iframe gets redirected to
        **tds-method-url-frame-3ds-method-url**
        URL (Issuer ACS);
        :(7) Issuer ACS collects Payer Identity Data from browser;
        :(8) Issuer ACS notifies (using HTTP POST)
        **threeDSMethodNotificationURL** on completion;
        #Turquoise:(9) When notification is received gather **threeDSMethodData**.
        Base64Decode it and check **threeDSServerTransID**;
        #Turquoise:(10) Save **threeDSCompInd=Y** for the current Transaction;
        #Turquoise:(11) Return **3DS Method Done HTML Page**;
    fork again
        note left
        **3DS Method HTML Page** lifecycle
        end note
        repeat
            #Turquoise:(12) Check if Issuer ACS notification
            is received from iframe internal JavaScript;
        repeat while ((13) notification is recieved OR timeout exceeded?) is (no)
        -> (yes);
        if ((14) timeout exceeded?) then (yes)
            #Turquoise:(15) Save **threeDSCompInd=N**
            for the current Transaction;
        else (no)
        endif
        :(16) After executing 3ds method\nsend data to connecting party's server;
   end fork
    else (no)
        #Turquoise:(17) Save **threeDSCompInd=U**
        for the current Transaction;
endif
#Turquoise:(18) Send **api/3ds/v1/upload-method-url-result/** request
with the collected Payer's data and **threeDSCompInd**,
Payer's browser info and **notificationURL**
which is to be used further in the Challenge Flow
(see 3DS Decision Making Schema and 3DS 2.X Challenge Flow).;
#Turquoise:(19) Send **/api/v2/status/** API request
Process **/api/v2/status/** response and follow **3DS Decision Making Schema**.;
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

Connecting party has to implement all steps marked in green. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(2) The same as point (1).
 
(4) To construct 3DS Method HTML page see [example](#frictionless-3ds-method-html-page-overview) below.
 
(9) To process 3DS Method Notification see [Process 3DS Method Notification](#frictionless-3ds-method-process-3ds-overview).
 
(11) To construct 3DS Method Done HTML page see [example](#frictionless-3ds-method-done-html-page-overview).
 
(18) To upload method url result see [/api/3ds/v1/upload-method-url-result/](https://doc.payneteasy.com/integration/API_commands/upload-method-url-result.html.md).
 
(19) The same as point (1).
 

###### 3DS Method HTML Page Example

3DS Method HTML Page example below performs 3DS Method initiation through iframe technique and holding of the Payer’s browser until the 3DS Method is not finished on the Connecting Party server. Once it is finished or timeout is reached Connecting Party has to follow the next steps following 3DS Decision Making Schema and redirect Payer’s browser to the corresponding URL (either Challenge Flow or payment result page). Normal timeout value is 30 sec.

3DS Method HTML Page consists of the following parameters:

| Parameter | Description |
|-------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| tds-method-url-frame-3ds-method-url | ACS 3DS Method URL is received by the Connecting Party in the [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md) response. |
| tds Method Upload Url | Connecting Party’s URL, where the result comes after the completion of the flow. |
| threeDSMethod Data | JSON value containing threeDSServer TransID and threeDSMethod NotificationURL. See below how to [construct threeDSMethod Data](#frictionless-3ds-method-html-page-threedsmethoddata-overview). |

**Construct threeDSMethod Data**

In order to **construct threeDSMethod Data** the Connecting Party has to use the following parameters.

| Parameter | Description |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| threeDSServer TransID | Universally unique transaction identifier assigned by the 3DS Server to identify a single transaction. Received in the [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md) response as tds-method-url-frame-3ds-server-trans-id parameter. |
| threeDSMethod NotificationURL | The URL that will receive the notification of 3DS Method completion from the ACS. The Connecting Party is responsible for providing valid threeDSMethod NotificationURL. Normally when the Connecting Party receives any request on this URL is has to return 3DS Method Done HTML Page (see [example](#frictionless-3ds-method-done-html-page-overview) below). |

**threeDSMethod Data construction example**

1. **Construct threeDSMethod Data** JSON.

```http
{"threeDSServerTransID":"3d671629-a410-4a5d-9288-b38ceadd41f2","threeDSMethodNotificationURL":"https://connectingparty.com/3ds-method-complete/"}
```

1. Apply base64 url encoding to resultant JSON.

```http
eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjNkNjcxNjI5LWE0MTAtNGE1ZC05Mjg4LWIzOGNlYWRkNDFmMiIsInRocmVlRFNNZXRob2ROb3RpZmljYXRpb25VUkwiOiJodHRwczovL21lcmNoYW50LmNvbS8zZHMtbWV0aG9kLWNvbXBsZXRlLyJ9
```

**Generate Fingerprint**

The 3DS Method can be optionally used by issuers to gather browser fingerprints using Java Script. This is done by loading a URL in a hidden iframe, before the authentication. This iframe will then execute some fingerprinting Java Script, before POST’ing to the prespecified URL belonging to the requestor. The 3DS Method fingerprint result is tied to the authentication by the threeDSServer TransID.

```js
function gatherBrowserData() {
  var colorDepth = screen.colorDepth; // 24
  var javaEnabled = navigator.javaEnabled(); // true
  var browserLanguage = navigator.language; // en_US
  var screenHeight = screen.height; // 1080
  var screenWidth = screen.width; // 1920
  var userAgent = navigator.userAgent; // Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.110 Safari/537.36
  var browserTimezoneZoneOffset = new Date().getTimezoneOffset(); // 0
}
```

**Construct 3DS Method HTML page example**:

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8"/>
    <title>ACS v2 3DS Method ...</title>
    
    <script>
var fallbackTimeout = null;
function processForm() {
    document.title = "ACS v2 AReq ...";
    document.getElementById( "browserJavaEnabled"       ).value = navigator.javaEnabled();
    document.getElementById( "browserJavascriptEnabled" ).value = true;
    document.getElementById( "browserLanguage"          ).value = navigator.language;
    document.getElementById( "browserColorDepth"        ).value = screen.colorDepth;
    document.getElementById( "browserScreenHeight"      ).value = screen.height;
    document.getElementById( "browserScreenWidth"       ).value = screen.width;
    document.getElementById( "browserTZ"                ).value = new Date().getTimezoneOffset();
    document.autoForm.submit();
}
function onPostMessage(event) {
    if(!event.data.hasOwnProperty('methodNotification')) {
       return;
    }
    if(fallbackTimeout != null) {
         clearTimeout(fallbackTimeout);
         fallbackTimeout = null;
    }
    document.getElementById( "threeDSCompInd" ).value = 'Y';
    processForm();
}
function onPageLoaded() {
    fallbackTimeout = setTimeout(processForm, 10 * 1000);
    document.methodForm.submit();
    window.addEventListener('message', onPostMessage);
}
    </script>
</head>
<body onload="onPageLoaded()">

    <div class="color"></div>

<iframe style="width:0; height:0; border:0;" name="methodFrame"></iframe>
<form name="methodForm" target="methodFrame" action="[=tds-method-url-frame-3ds-method-url]" method="POST">
    <input type="hidden" name="threeDSMethodData" value="[=threeDSMethodData]">
</form>
<form name="autoForm" action="[=tdsMethodUploadUrl]" method="post">
    <input type="hidden" name="threeDSServerTransID" value="[=threeDSServerTransID]"/>
    <input type="hidden" name="threeDSCompInd" id="threeDSCompInd" value="N"/>
    <input type="hidden" name="browserJavaEnabled"       id="browserJavaEnabled"        value="" />
    <input type="hidden" name="browserJavascriptEnabled" id="browserJavascriptEnabled"  value="" />
    <input type="hidden" name="browserLanguage"          id="browserLanguage"           value="" />
    <input type="hidden" name="browserColorDepth"        id="browserColorDepth"         value="" />
    <input type="hidden" name="browserScreenHeight"      id="browserScreenHeight"       value="" />
    <input type="hidden" name="browserScreenWidth"       id="browserScreenWidth"        value="" />
    <input type="hidden" name="browserTZ"                id="browserTZ"                 value="" />
    <noscript>
        <input type="submit" name="submit" value="Upload 3DS Method Result"/>
    </noscript>
</form>
</body>
</html>
```

###### Process 3DS Method Notification

When 3DS Method is completed, the Connecting Party receives HTTP POST request at threeDSMethod NotificationURL with threeDSMethod Data, which contains threeDSServer TransID (in base64 encoded JSON).

1. Get threeDSMethod Data.

```js
threeDSMethodData=eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6IjNkNjcxNjI5LWE0MTAtNGE1ZC05Mjg4LWIzOGNlYWRkNDFmMiJ9Cg
```

1. Apply base64 url decoding to get JSON, which contains threeDSServer TransID.

```json
{"threeDSServerTransID":"3d671629-a410-4a5d-9288-b38ceadd41f2"}
```

###### 3DS Method Done HTML Page Example

```html
<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8"/>
    <title>ACS v2 3DS Method Notification Handler...</title>
    <script>
        window.parent.postMessage({ methodNotification: "COMPLETE" }, "*");
    </script>
</head>
<body>
<p>This should not be displayed</p>
</body>
</html>
```

##### 3DS 2.x.0 Challenge Flow

```plantuml

title 3DS 2.x.0 Challenge Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**tds-creq-form-creq**
**tds-creq-form-acs-url**;
#Turquoise:(3) Construct CReq HTML Page based on the gathered parameters.
Add **threeDSSessionData** with the custom data
in the format: Max length: 1024 bytes, format: Alphanumeric,
base64url encoded without padding.;
#Turquoise:(4) Return CReq HTML Page to Payer's browser;
:(5) CReq Page gets redirected to ACS URL **tds-creq-form-acs-url**.
Payer passes 3DS Challenge Verification.
ACS return CRes Page.
CRes Page gets submitted to **notificationURL**;
#Turquoise:(6) Process CRes Page parameters.
Gather parameters:
**cres**
**threeDSSessionData**;
#Turquoise:(7) Send HTTP POST **/api/3ds/v1/upload-cres-result/** API Request
providing **cres**, **orderid=paynet-order-id**;
#Turquoise:(8) Send **/api/v2/status/** API request
Process **/api/v2/status/** response and follow **3DS Decision Making Schema**.;
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(2) The same as point (1).
 
(3) To create CReq HTML Page see [example](#creqform-example-overview).
 
(5) To implement CRes redirect see [CRes redirect](https://doc.payneteasy.com/integration/API_commands/CRes_redirect.html.md).
 
(7) To upload CRes result see [/api/3ds/v1/upload-cres-result/](https://doc.payneteasy.com/integration/API_commands/upload-cres-result.html.md).
 
(8) The same as point (1).
 

###### CReq HTML Page Example

CReq HTML Page redirects the Payer’s browser to ACS Server URL, provided in tds-creq-form-acs-url parameter. The result CRes value will be returned from ACS to notificationURL provided by Connecting Party in [/api/3ds/v1/upload-method-url-result](https://doc.payneteasy.com/integration/API_commands/upload-method-url-result.html.md) request during 3DS 2.x.0 Frictionless Flow.

| Field | Description | Necessity |
|--------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| creq | ACS 3DS CReq data, which received by the Connecting Party in the [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md) response. The same as tds-creq-form-creq. | Required |
| threeDSSession Data | value which will be posted back within CRes to notificationURL at the end of the process. Max length: 1024 bytes, format: Alphanumeric, Base64url encoded without padding. | Optional |
```html
<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>Redirecting ...</title>
  <script type="text/javascript" language="javascript">
    function makeSubmit() {
              document.returnform.submit();
        }
  </script>
</head>
<body onLoad="makeSubmit()">
<form name="returnform" action="https://acs.bank-domain.com/mdpayacs/creq" method="POST">
  <input type="hidden" name="creq" value="eyJ0aHJlZURTU2VydmVyVHJhbnNJRCI6ImM1NDA5N2VhLTc0ZTctNDE2My05MTQ4LTNjMTY1NTg3NGIwMCIsImFjc1RyYW5zSUQiOiIxMjU1NTkyMi1lZmYzLTRjOTQtOTk4Mi0yMDM3NjJhMzdmMjkiLCJjaGFsbGVuZ2VXaW5kb3dTaXplIjoiMDIiLCJtZXNzYWdlVHlwZSI6IkNSZXEiLCJtZXNzYWdlVmVyc2lvbiI6IjIuMS4wIn0=">
  <input type="hidden" name="threeDSSessionData" value="NjY4MDU3NQ">
  <noscript>
    <input type="submit" name="submit" value="Press this button to continue"/>
  </noscript>
</form>
</body>
</html>
```

##### 3DS 1.0.2 Authentication Flow

```plantuml

title 3DS 1.0.2 Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**tds-pareq-form-pareq**
**tds-pareq-form-acs-url**;
#Turquoise:(3) Construct PAReq HTML Page based on the gathered parameters.
Add **TermUrl** where the Payer gets redirected back with PARes data submitted.
Add **MD** with the custom data which is be posted back.;
#Turquoise:(4) Return PAReq HTML Page to Payer's browser;
:(5) PaReq Page gets redirected to ACS URL **tds-pareq-form-acs-url**;
:(6) Payer passes 3DS Challenge Verification;
:(7) ACS returns PARes Page;
:(8) PaRes Page gets submitted to the **TermUrl**;
#Turquoise:(9) Process PARes Page parameters.
Gather parameters:
**PaRes**
**MD**;
#Turquoise:(10) Send HTTP POST **/api/3ds/v1/upload-pares-result/** API Request
providing **paRes**, **orderid=paynet-order-id**;
#Turquoise:(11) Send **/api/v2/status/** API request
Process **/api/v2/status/** response and follow **3DS Decision Making Schema**.;
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(2) The same as point (1).
 
(3) To construct Pa Req HTML Page see [example](#pareqform-example-overview).
 
(5) To implement Pa Res redirect see [Pa Res redirect](https://doc.payneteasy.com/integration/API_commands/Pa Res_redirect.html.md).
 
(10) To upload Pa Res result see [/api/3ds/v1/upload-pares-result/](https://doc.payneteasy.com/integration/API_commands/upload-pares-result.html.md).
 
(11) The same as point (10).
 

###### Pa Req HTML Page Example

Pa Req HTML Page redirects the Payer’s browser to ACS Server URL, provided in tds-pareq-form-acs-url parameter.

Pa Req HTML Page consists of the following parameters:

| Field | Description | Necessity |
|------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| tds-pareq-form-acs-url | ACS 3DS Pa Req URL is received by the Connecting Party in the [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md) response. | Required |
| MD | Connecting Party Data, which comes back to your termination page. | Optional |
| Pa Req | ACS 3DS Pa Req data, which received by the Connecting Party in the [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md) response. The same as tds-pareq-form-pareq. | Required |
| TermURL | URL of termination page, where the Payer gets redirected back with Pa Res data submitted. | Required |
```html
<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8">
  <title>Loading acs..</title>
  <script type="text/javascript" language="javascript">
    function makeSubmit() {
      document.returnform.submit();
    }
  </script>
</head>
<body onLoad="makeSubmit()">
<form name="returnform" action="$tds-pareq-form-acs-url" method="POST">
  <input type="hidden" name="MD" value="some_merchant_data"/>
  <input type="hidden" name="PaReq" value="$tds-pareq-form-pareq"/>
  <input type="hidden" name="TermUrl" value="https://termination.page"/>
  <noscript>
    <input type="submit" name="submit" value="Submit"/>
  </noscript>
</form>
</body>
</html>
```

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL (value of redirect-to parameter);
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
             **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
             **Connecting Party Server** lifecycle
end note
repeat
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response;
repeat while ((17) Received final status from "Payneteasy") is (no)
-> (yes);
#Turquoise:(18) Save transaction status;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(2) The same as point (1).
 
(6) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(7) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(12) and (13) The same as point (1).
 

#### Alternative cardholder authentication

Payment Gateway supports alternative methods for cardholder authentication if card is not enrolled to 3DS (negative 3DS enrollment response). One of such methods is random sum check. In this method, Payment Gateway initiates an additional preauthorization transaction to hold a random small amount on cardholder’s account and sends a special form for the Payer to enter the amount being held. If the amount is correct, Payment Gateway continues to process the initial transaction. The small amount hold is cancelled automatically.

##### General diagram for form transactions

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
actor Payer as Customer
participant "Connecting Party" as Merchant
participant "Payment Gateway" as g
autonumber
Customer -> Merchant: Checkout
activate Merchant
== Purchase payment request ==
Merchant -> g: Request Initiating
activate g
g --> Merchant: Redirect-url, Order ID
deactivate g
Merchant -> Customer: Provide redirect-url to Payer's browser
activate Customer
Customer -> g: GET redirect-url
deactivate Customer
activate g
g -> Customer: Payment Form
deactivate g
activate Customer
Customer -> g: Submit Form
deactivate Customer
activate g
g -> g: Transaction processing
g -> g: 3DS Enrollment
g -> g: Random Sum Processing
g -> Customer: Redirecting to the Random Sum Check html form
deactivate g
activate Customer
Customer -> g: The cardholder provides auth data
deactivate Customer
activate g
g -> g: Auth Data Validating
group alt
== Receive Connecting Party Callback ==
Merchant <- g: Сallback with final status
g <-- Merchant: HTTP 200
deactivate g
== Order Status Request ==
Merchant -> g: api/v2/status
activate g
g --> Merchant: Response \nstatus, order-stage
deactivate g
end
Merchant --> Customer: Show result
deactivate Merchant
deactivate Customer
```

(2) See relevant Use-Case to get details about the exact API command to initiate transaction.
 
(13) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(15) Please see [Status List](https://doc.payneteasy.com/integration/statuses.html.md) to get more information about Final Statuses.
 

##### General diagram for direct integrations

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payment Gateway" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: Payment Initiating
activate B
B --> A: Order ID
B -> B: Transaction processing
group loop
A -> B: Status Request
B --> A: Non-Final Status
end
B -> B: 3DS Enrollment
B -> B: Random Sum Processing
A -> B: Status Request
B -> A: Response with Random Sum Check html form
A -> Payer: Redirecting to the Random Sum Check html form
deactivate B
activate Payer
Payer -> B: Cardholder provides auth data
deactivate Payer
activate B
B -> B: Auth Data Validating
group alt
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Response status, \norder-stage
deactivate B
end
A --> Payer: Show result
deactivate A
```

(2) See relevant Use-Case to get details about the exact API command to initiate transaction.
 
(9) Status Request continues in parallel all the time starting from step 5.
 
(11) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(13) Please see [Status List](https://doc.payneteasy.com/integration/statuses.html.md) to get more information about Final Statuses.

### API Commands, Callbacks & Redirects

### CRes Redirect

#### CRes Redirect Parameters

CRes redirect to connecting party’s website is performed when a payer ends Challenge flow. Final redirect is initiated from within payers browser using HTTP POST method.
HTTP payload contains CRes parameters which in turn contains base64 encoded json (see example below).

| Redirect parameter name | Description |
|---------------------------|-------------------------------------------------------------------------------------|
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant |
| merchant-order-id | Merchant order id |
| paynet-order-id | Order id assigned to the order by gate.payneteasy.eu |

#### Redirect Request Example

Connecting party receives HTTP POST request base64 encoded **CRes** parameter similar to below:

```http
cres=ewogICJtZXNzYWdlVHlwZSIgICAgOiAiQ1JlcyIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCgogICJ0aHJlZURTU2VydmVyVHJhbnNJRCIgOiAic29tZVRocmVlRFNTZXJ2ZXJUcmFuc0lEIiwKICAiYWNzVHJhbnNJRCIgICAgICAgICAgIDogInNvbWVBY3NUcmFuc0lEIiwKCiAgImNoYWxsZW5nZUNvbXBsZXRpb25JbmQiIDogIlkiLAogICJ0cmFuc1N0YXR1cyIgICAgICAgICAgICA6ICJZIgp9
```

After decoding cres one will find a json similar to below:

```json
{
  "messageType"    : "CRes",
  "messageVersion" : "2.1.0",

  "threeDSServerTransID" : "someThreeDSServerTransID",
  "acsTransID"           : "someAcsTransID",

  "challengeCompletionInd" : "Y",
  "transStatus"            : "Y"
}
```

### Pa Res Redirect

#### Pa Res Redirect Parameters

Pa Res redirect to connecting party’s website is performed when a payer ends 1.0.2 authentication flow.
Final redirect is initiated from within payers browser using HTTP POST method.
HTTP payload contains Pa Res parameters which in turn contains base64 encoded json (see example below).

| Redirect parameter name | Description |
|---------------------------|-------------------------------------------------------------------------------------|
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant |
| merchant-order-id | Merchant order id |
| paynet-order-id | Order id assigned to the order by gate.payneteasy.eu |

#### Redirect Request Example

Connecting party receives HTTP POST request deflate archived base64 encoded Pa Res parameter similar to below:

```http
paRes=eJydlluTokgThu/nVxhOxN4YPZwV5rPdKI6CgHIQxTsaEDnIWUB//aL09Ngdc7HfcgFFkvnwZmVWRc3/7s7JqPHLKszS1zHyAx6P/NTNvDANXsdbk38hx6OqdlLPSbLUfx2n2fjvxdw8lb7PGr57Kf3Ft9FoNFf8qnICfxR6r2P4/Xr5dUM+Rv01JY6edxw/wu6RG6D71f8fdw99173oZf9A59Cv1ycPxS/dk5PWT7a72XELWlQXOIJMCXIOvb9+9jn7pcguEBTDiemMpOA5NFie6NAf8PPN5W6r/C+4LvQWamTjKstdVZhRuPwk8vvOkKPDbt2A1zl09/gc4zm1v0BhFEFgdDaC0Z8I/BPvE33YP7v2lSj7wl0XUxybQx9vn538Lu+L2MvtGR/jzy75XT04Z5f+C3Kf9jn0bHpO/g+JznMnXcxQjIBRlJgRBIGi6Gw6JQmSmvU2pJ/ru8dTgLn/IqAOz59zxqmfBDGHHvbPrn1f1pdqYc+h99GXbN1wAfeR9+ez7t+/7HO4N9/QwUYYpD2l9Ef9kkir1/GprvOfENS27Y8W+5GVAYT28wHBFNQ7eFUYfB8vHlG+J6bHbDFnnDRLQ9dJwptT942o+PUp80YgCbIyrE/nPyFN/U5FIJ1jXnrsi4vg6cvdAmMIMYYWv2X9G9pXgWXlvFQnB7mDdP/o35vCH2118XX8/d+ttjkbBn5V/5ef//rxQLCc5OIvVLFd0tZGl5PaWkMNtmqIDYDqdQnh/Qp49pxDH4L78fM0f8zI4ChXgtEZhyIt0K6WdJy5vhUC2dnwKScKue1cfDNt8ZlKzFaheInrfQNtd44xWZaSiTh2q+mWZ6gTqN0I7F/fEex/31QZhlr2sgOIutoh2tlvOKiBsCyuaDTx1ifdz72tLNgXrcJ8xvBpouWza+G0+DJwILpyCkrN+Qll5idnIIoYvK3WmLDCzukJmxWQkjmkncm0S7jN7AbsSA9xDGwm1ZbxogMeHwywYgpR32FwNUHla0rGF5ZChN2qGIjsmfYPqJQIlGKqWcLoYMXVuupPJrk+ESZhh+5YCIrVYi1NCDoPpWXrOuky80TBzLRbmsxcoKAcRs6C/UAs5KVhozuIn/oB7iH224yPfBviFW7Ke911RebqRQleX4diPBVgvvKvQ2X2BEyxTu0MI8Yv6/DYr4d+s1JEkd2yDAOigGE05mY62yk6YW+HG1DpIC5OcShQLUwDreIBSxeKVrWMZrOWpglcK9k7lpMVEAsA2XKDXAa0zI4POs4EGzpQLRq4CsPriYvpkbPXCUXXWi54EFYsqLeHvQprKFW7An/xTU5XAPmgMW0rDkRLsG4eb12cvdZxEdAGqqIw1oNK25jSKibw+Ra+9k9CYeNOMblbXwDnYYt+2wbi/YsiZB1zA9JAs02QnOyn7EQWPLL70EP3eh5KBDX3lnHHs8C4xw5EGmQKgzz0sG8o0to7os+Ua9n2QZNZcHpkau2I3GM5Q6HBgwraVnpQOT5yb6Dr60G/t2b0tQIcD8CaARoJ7l5MsOrHHECQws5DYVJaBy5MOjzbe3GL+JjH0NaK4Fy53xoGorGKpfqYi2wDgSu8v8UJFC831Zt8pRhCQmK3K0wYz3QxMLeacHEsam0Gld1SwnIWQKR6EN84ZT2N6F2yG4gJqabAXreFaDh2pcrbyJZo/GAdaCWIeaXgSpFgGdN0Qbd+Q69YZbilJEWWVfjTc3EKOXrvULeio4woHojt4TpDqBPxpsrTmshXpLnd8Yl7zWaYpdRtgFsk1pDAMugusQBIrJp3G9DYcllPrh2JGLGVLtE9pl4kZiCetLXfyDY8WW4beD/btHbphr2inYQRgqhY0Cw/LI03wfCCIxxCFdvcWKEHZJ2A7+ibdlsXtIGtnOzW5QMRa/vm0ACtAFhgjEIwxDeM1TiaabcA4GJfKZpIG87BcaqY6da6ZByDu1x1WyHI2yTh4BsxwQz5LYowfiBGhcupZ4/zk9UVeGQLKzB3nZS7xGFX2rrOupaLkq00QSZr0loiql4yjeBsjpJtxlvnyGIrfyn1fYutdu8dnjNxkqCqvAq3pmDlR+QApwpWoUZsg6iaIC61OU6yvTpLwgt0FVW2wVXytJajOF+SmL3ZSxRqvWktdbm+d3hE+RtJ2/gGdswlzoeJGK0tqk21NaVFbkfthLUCkfLyIBy8oyi1K2epL/GqPbrttVQamLLcDWSk28Su39d1UyRkgxZ2sybgTC+9DK4PRiNLOyKZGmZ18qMqv+jQ8lozEKVHDELWuJpSvHWeuSzC9eekmaqJq3oOfd3VBsuw40Efu+Dv/XFxPyE+zsWLb/254/nQ/A8pzm2f
```

After decoding pa Res one will find a xml similar to below:

```xml
<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<ThreeDSecure>
   <Message id="00000000-0000-0001-0000-00000065fddf">
      <PARes id="00000000-0000-0001-0000-00000065fddf">
         <version>1.0.2</version>
         <Merchant>
            <acqBIN>411658</acqBIN>
            <merID>1234567890</merID>
         </Merchant>
         <Purchase>
            <xid>NjY4NDEyN0CMEphIFXxSLjZWOvA=</xid>
            <date>20211027 02:10:42</date>
            <currency>643</currency>
            <exponent>2</exponent>
            <purchAmount>10000</purchAmount>
         </Purchase>
         <pan>7235022575552227668589750218</pan>
         <TX>
            <time>20211027 02:49:55</time>
            <status>Y</status>
            <eci>05</eci>
         </TX>
      </PARes>
   <Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
            <SignedInfo>
                <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
                <SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
                <Reference URI="#00000000-0000-0001-0000-00000065fddf">
                    <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
                    <DigestValue>NIwHBVPRLltVO/v3Kv5PA/tOr/4=</DigestValue>
                </Reference>
            </SignedInfo>
            <SignatureValue>LsGSxSZqnq2xtJR4CybqG8xY0hp5qLwxc4P6w47N57KiIuktXv/UWaS+HrJT1aYwQRVdSN+/wPGD&#13;
NL0/wDuWA1NKW1QmevE/v/3oksB2ldOhRepdULGYuQs3eCSeB5wFoyqaw4Hga/Bsaq9NpF+9Tpha&#13;
I30UsO3GK3mnh37q/Moa8YoLBc5cv7zAYjRi43AP+sUCdjZ4kZSAKCqIRW30s+2Lyn8kuD91GWKq&#13;
DmBeZ2JlG9MTNolCRAKEtRNe++pR+G+ix2WD//kNqOJ+5BpiJHwcanHodIGToQznl7cAM2E387gX&#13;
qLHSY2W/F6eg4d1Yb7FjeY/FME6FdxyK8pNuMg==</SignatureValue>
            <KeyInfo>
                <X509Data>
                    <X509Certificate>MIIDUDCCAjgCCQCzTaU62+DzZzANBgkqhkiG9w0BAQsFADBqMQswCQYDVQQGEwJYWDELMAkGA1UE&#13;
CAwCWFgxETAPBgNVBAcMCFRlc3RjaXR5MRQwEgYDVQQKDAtUZXN0Q29tcGFueTERMA8GA1UECwwI&#13;
VGVzdFVuaXQxEjAQBgNVBAMMCVRlc3RBY3MwMTAeFw0yMTA5MDkxMTEzMTNaFw0yMjA5MDkxMTEz&#13;
MTNaMGoxCzAJBgNVBAYTAlhYMQswCQYDVQQIDAJYWDERMA8GA1UEBwwIVGVzdGNpdHkxFDASBgNV&#13;
BAoMC1Rlc3RDb21wYW55MREwDwYDVQQLDAhUZXN0VW5pdDESMBAGA1UEAwwJVGVzdEFjczAxMIIB&#13;
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA11qYpiG+rVZEilx4oXdkw1e3dCBVK5EcLlgo&#13;
SKkJtfpIDv/Ay0Xzkl/kHPsbLy9C5J1kcxqT04oRIgTUQGuaV9OTgsYw9GH7g/8NZIbEMO6jBWlW&#13;
l8NnAYOwqISaYsNLUjYJB4ZVZBMgkFMqErI5DCTTcAxOb2y3sScrJJjVVqe6mqhiEBXa9zqx9Sjk&#13;
wZy719h5bNL6t5pK8TUWFlcyo73VMtwg4V83v8AVSBxlVAAlVtFcvAvYLrt+yx81SkVnH2X3NuJC&#13;
hQOevLY0+HUv0X7PwYrciTcAWJ35GIMV/7pZHSbGSdgf0i/sDvzDGX3NoxG4WBzQzOqBS3Kaozxp&#13;
3wIDAQABMA0GCSqGSIb3DQEBCwUAA4IBAQB5nvEa449q7RVOrCaSEuyRYM58z+lE0z5+3SLbjj3F&#13;
jqcENmdEelKyAd8w0M0Ey+rWlaDKQOtoxwEjlUJ+1+O8VH1NRrCvGaPfJYTkUafD3KeHJQYD3KWz&#13;
pCkll2NLKiUTGVpf1Z0nM3s2SkYAjs+1c9Pf+oXN7liu/yINDv4N8hOLjkpH83YPXJ92VbQw9uyV&#13;
j9ePJQPeS3fpJEe05k2tV9wnQO9Qjcx9WGOM/8LHZGZdfIJwKaHRH4swfcwyrMv09VcP/SnUlYtI&#13;
vql8v2qYvO50oRrdo0tZSvLJW5l6STshejspuR/HytC/9RjC18t4Nn9FVm7cD1Expo7NQIKt</X509Certificate>
                </X509Data>
            </KeyInfo>
        </Signature>
    </Message>
</ThreeDSecure>
```

### Account Verification Form

#### Introduction

Account verification is a non-financial transaction, which allows to validate Payer’s card account information. This verification procedure helps to prevent potential fraudulent activity and meet industry-specific compliance obligations. Account Verification Form integration allows Connecting Party to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted payment form in PCI DSS certified environment.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Account Verification Form Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Account Verification Request ==
  Merchant -> g: api/v2/account-verification-form
  activate g
  g --> Merchant: Redirect-url, orderId
  deactivate g
  Merchant -> Customer: Provide redirect-url \nto payer’s browser
  deactivate Merchant
  activate Customer
  Customer -> g: GET redirect-url
  deactivate Customer
  activate g
  g --> Customer: Account Verification Form
  deactivate g
  activate Customer
  Customer -> g: Submit form
  deactivate Customer
  activate g
  g --> g: Process Account Vetification transaction
  == Final redirect of customer ==
  g -> Customer: Redirect to Connecting Party website
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  activate Merchant
  group Get Final Status
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant --> Customer: Show result
  deactivate Merchant
```

(2) To implement Account Verification Form request see [/api/v2/account-verification-form/](https://doc.payneteasy.com/integration/API_commands/api_v2_account-verification-form.html.md).
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11,12) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(13) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).

### /registry/upload

#### Introduction

This API allows Manager to upload a file with adjustments for Merchant balance in Payment Gateway.

#### Adjustments parameters

Adjustments must be sent in archived tsv file format.

| Parameter | Description |
|----------------------|-----------------------------------------------------------------------------------|
| Credit amount | Credit amount. |
| Debit amount | Debit amount. |
| External ID | Adjustment external ID. |
| External Merchant ID | External merchant ID. Set in properties of merchant/manager. |
| Balance name | Balance name. If parameter is not set, default balance is automatically selected. |

#### File example

tsv file example:

```html
10.45               eid1    THIS_IS_EXT_MERCH_ID    Global merchant balance
90.05               eid2    THIS_IS_EXT_MERCH_ID    Global merchant balance
```

### Add Document

#### Introduction

Add Document allow to send request with document to attach it to the specific transaction. It is possible to attach any additional document to the existing transaction in the Payment Gateway. The attached document can be later downloaded from order details screen. This page describes how to attach the document to transaction by API.

#### Add Document Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
hnote over A,B : Relevant Payment Flow

A -> A: Collect Documents
activate A
A -> B: Request to attach documents by Order ID
deactivate A
activate B
B -> B: Request confirmed
B -> B: Attach Document to transaction
activate A
B -> A: Document has been attached
deactivate B
deactivate A
```

(2) Each transaction in the System has assigned Order ID. Connecting Party makes upload document request to attach it to the specified transaction by Order ID, using [/api/v2/documents/add-document](https://doc.payneteasy.com/integration/API_commands/api_v2_add-document.html.md).

### Check sale

#### Introduction

Check sale is initiated through HTTPS POST request by using [URLs](#api-url-check-sale) and the [parameters](#api-parameters-check-sale).
 
Check sale is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server.
 
It is highly recommended to respond with the actual information stored on Connecting Party’s server.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|----------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/sale/{invoice Id}/check |

#### Request Parameters

| Parameter Name | Description | Value |
|--------------------------------------|----------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Consumer’s access token key sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.nonce | Value sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.signature | Value sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.token | The session token of sale transaction. | `Necessity`: Required `Type`: String `Length`: 16-36 |
| source Of Funds | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference.client Card Id | The source card reference identifier (on client side) if sent in Perform sale request. | `Necessity`: Optional `Type`: String `Length`: 1-128 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|--------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|
| invoice Id | Sale transaction identifier | `Necessity`: Required `Type`: String |
| session | | `Necessity`: Required `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of the consumer.device.serial Number, session.nonce, endpoint Id, invoice Id, source Of Funds.reference.server Card Id (if present). | `Necessity`: Required `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server in Initiate sale response. | `Necessity`: Required `Type`: String |
| session.token | The session token of sale transaction. | `Necessity`: Required `Type`: String |
| consumer.email | Сonsumer’s email address, if sent in original card mapping transaction. | `Necessity`: Optional `Type`: String |
| source Of Funds | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference.server Card Id | The source card reference identifier (on server side). | `Necessity`: Optional `Type`: String |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Optional `Type`: String |
| transaction.random Sum Centis | Random sum amount (for random sum check), 1.00 EUR = 100 centis. | `Necessity`: Optional `Type`: Integer |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Sale transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string",
    "token": "string"
  },
  "sourceOfFunds": {
    "reference": {
      "clientCardId": "string"
    }
  }
}
```

#### Success Response Example

```json
{
  "consumer": {
    "email": "string"
  },
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  },
  "sourceOfFunds": {
    "card": {
      "expiry": {
        "month": "integer",
        "year": "integer"
      },
      "holder":{
        "firstName": "string",
        "lastName": "string"
      },
      "number": "string"
    },
    "reference": {
      "serverCardId": "string",
    }
  },
  "transaction": {
    "currency": "string",
    "randomSumCentis": "integer"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Check transfer

#### Introduction

Check transfer is initiated through HTTPS POST request by using [URLs](#api-url-check-transfer) and the [parameters](#api-parameters-check-transfer).
 
Check transfer is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server.
 
It is highly recommended to respond with the actual information stored on Connecting Party’s server.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|--------------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/transfer/{invoice Id}/check |

#### Request Parameters

| Parameter Name | Description | Value |
|-------------------------------------------|-------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Consumer’s access token key sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.nonce | Value sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.signature | Value sent by Connecting Party’s app. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.token | The session token of transfer transaction. | `Necessity`: Required `Type`: String `Length`: 16-36 |
| source Of Funds | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference.client Card Id | The source card reference identifier (on client side) if sent in Perform Transfer request. | `Necessity`: Optional `Type`: String `Length`: 1-128 |
| destination Of Funds | | `Necessity`: Optional `Type`: **Object** |
| destination Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| destination Of Funds.reference.client Card Id | The destination card reference identifier (on client side) if sent in Perform Transfer request. | `Necessity`: Optional `Type`: String `Length`: 1-128 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|-------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|
| invoice Id | Transfer transaction identifier. | `Necessity`: Required `Type`: String |
| session | | `Necessity`: Required `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of the consumer.device.serial Number, session.nonce, destination Of Funds.reference.server Card Id (if present), endpoint Id, invoice Id, source Of Funds.reference.server Card Id (if present). | `Necessity`: Required `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server in Initiate transfer response. | `Necessity`: Required `Type`: String |
| session.token | The session token of transfer transaction. | `Necessity`: Required `Type`: String |
| consumer.email | Consumer’s email address. | `Necessity`: Optional `Type`: String |
| destination Of Funds | | `Necessity`: Optional `Type`: **Object** |
| destination Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| destination Of Funds.reference.server Card Id | The destination card reference identifier (on server side). | `Necessity`: Optional `Type`: String |
| source Of Funds | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference | | `Necessity`: Optional `Type`: **Object** |
| source Of Funds.reference.server Card Id | The source card reference identifier (on server side). | `Necessity`: Optional `Type`: String |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Optional `Type`: String |
| transaction.random Sum Centis | Random sum amount (for random sum check), 1.00 EUR = 100 centis. | `Necessity`: Optional `Type`: Integer |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Transfer transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "destinationOfFunds": {
    "reference": {
      "clientCardId": "string"
    }
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string",
    "token": "string"
  },
  "sourceOfFunds": {
    "reference": {
      "clientCardId": "string"
    }
  }
}
```

#### Success Response Example

```json
{
  "consumer": {
    "email": "string"
  },
  "destinationOfFunds": {
    "card": {
      "number": "string"
    },
    "reference": {
      "serverCardId": "string"
    }
  },
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  },
  "sourceOfFunds": {
    "card": {
      "expiry": {
        "month": "integer",
        "year": "integer"
      },
      "holder":{
        "firstName": "string",
        "lastName": "string"
      },
      "number": "string"
    },
    "reference": {
      "serverCardId": "string",
    }
  },
  "transaction": {
    "currency": "string",
    "randomSumCentis": "integer"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Check verification

#### Introduction

Check verification is initiated through HTTPS POST request by using [URLs](#api-url-check-verification) and the [parameters](#api-parameters-check-verification).
 
Check verification is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server.
 
It is highly recommended to respond with the actual information stored on Connecting Party’s server.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|------------------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/verification/{invoice Id}/check |

#### Request Parameters

| Parameter Name | Description | Value |
|------------------------------|-------------------------------------------------------------|---------------------------------------------------------|
| consumer | | `Type`: **Object** |
| consumer.device | | `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Type`: String `Length`: 1-50 |
| session | | `Type`: **Object** |
| session.access Token | Consumer’s access token key sent by Connecting Party’s app. | `Type`: String `Length`: 32-128 |
| session.nonce | Value sent by Connecting Party’s app. | `Type`: String `Length`: 32-128 |
| session.signature | Value sent by Connecting Party’s app. | `Type`: String `Length`: 32-128 |
| session.token | The session token of verification transaction. | `Type`: String `Length`: 16-36 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|-----------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|
| invoice Id | Verification transaction identifier. | `Necessity`: Required `Type`: String |
| session | | `Necessity`: Required `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of consumer.device.serial Number, session.nonce, endpoint Id and invoice Id. | `Necessity`: Required `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server in Initiate verification response. | `Necessity`: Required `Type`: String |
| session.token | The session token of verification transaction. | `Necessity`: Required `Type`: String |
| billing | | `Necessity`: Optional `Type`: **Object** |
| billing.address | | `Necessity`: Optional `Type`: **Object** |
| billing.address.city | City name. | `Necessity`: Optional `Type`: String |
| billing.address.country | ISO alpha3 country code. | `Necessity`: Optional `Type`: String |
| billing.address.postcode Zip | ZIP post code. | `Necessity`: Optional `Type`: String |
| billing.address.state | State is used if present. For example, Los Angeles is in CA state. | `Necessity`: Optional `Type`: String |
| billing.address.street | Street is used for district names and street names. | `Necessity`: Optional `Type`: String |
| billing.address.street2 | Street 2 is used for long addresses. Usually it contains apartment and building №. | `Necessity`: Optional `Type`: String |
| billing.phone | Customer’s contact phone number. | `Necessity`: Optional `Type`: String |
| consumer.birth Day | Consumer’s birth day in “ddMMyyyy” format. | `Necessity`: Optional `Type`: String |
| consumer.email | Consumer’s email address. | `Necessity`: Optional `Type`: String |
| consumer.ip Addresses | Consumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Consumer’s IP address. | `Necessity`: Optional `Type`: String |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Optional `Type`: String |
| transaction.random Sum Centis | Random sum amount (for random sum check), 1.00 EUR = 100 centis. | `Necessity`: Optional `Type`: Integer |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Verification transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "billing": {
    "address": {
      "city": "string",
      "country": "string",
      "postcodeZip": "string",
      "state": "string",
      "street": "string",
      "street2": "string"
    },
    "phone": "string"
  },
  "consumer": {
    "birthDay": "string",
    "email": "string",
    "ipAddresses": ["string"]
  },
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  },
  "transaction": {
    "currency": "string",
    "randomSumCentis": "integer"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Complete Transfer

#### Introduction

Complete transfer is initiated through HTTPS POST request by using [URLs](#api-url-complete-transfer) and the [parameters](#api-parameters-complete-transfer).
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id}/{assigned Id} | https://gate.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id}/{assigned Id} |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------|---------------------------------------------------|------------------------------|
| session | | `Type`: **Object** |
| session.access Token | The session access token of transfer transaction. | `Type`: String |
| session.token | The session token of transfer transaction. | `Type`: String |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------|--------------------------------------------|------------------------------|
| invoice Id | Transfer transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of transfer transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `INVALID_REQUEST`, `INVALID_CONFIGURATION`, `INTERNAL_ERROR`, `PROCESSING_FAILED`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Transfer transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "session": {
    "accessToken": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Development tools

#### Introduction

#### Signature computation

The signature is being used to ensure that it is Connecting Party (and not a fraudster) who sends the information to Payneteasy.
 
Signatures in DAPI are computed using HMAC_SHA1 algorithm. Key is derived in the following way:
 
 
1. Take Connecting Party Control Key
2. Remove dashes from it
3. Unhex the result to binary

The correct signature values for all types of transactions supported by DAPI in the debugging tool below:
 
 
<meta http-equiv="Cache-Control" content="no-cache">
<script type="text/javascript" src="../../_static/js/crypto-js/core-min.js"></script>
<script type="text/javascript" src="../../_static/js/crypto-js/hmac-sha1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../../_static/js/highlight/styles/default.css">
<script src="../../_static/js/highlight/highlight.pack.js"></script>

<script type="text/javascript">
 var string Text = "";
 var hmac = "";
 var operation = "";

 function get Params() {
		//gathering the parameter rows to show and hide
		var a = document.get Element By Id("i Token");
		var b =	document.get Element By Id("i Serial Number");
		var c =	document.get Element By Id("i Tx Currency");
		var d =	document.get Element By Id("i Tx Amount");
		var e =	document.get Element By Id("i Destination");
		var f =	document.get Element By Id("i Source");
		operation = document.get Element By Id("operation Name").value;

	//shows and hides the parameter rows for different types of signatures
	switch (operation) {
	case "Init Verif Resp":
		a.style.display = '';
		b.style.display = '';
		c.style.display = '';
		d.style.display = 'none';
		e.style.display = 'none';
		f.style.display = 'none';
		break;
		case "Check Verif Resp":
			a.style.display = 'none';
			b.style.display = '';
			c.style.display = 'none';
			d.style.display = 'none';
			e.style.display = 'none';
			f.style.display = 'none';
			break;
			case "Mapping Resp":
				a.style.display = 'none';
				b.style.display = 'none';
				c.style.display = 'none';
				d.style.display = 'none';
				e.style.display = 'none';
				f.style.display = 'none';
				break;
				case "Init Transfer Or Sale Resp":
					a.style.display = '';
					b.style.display = '';
					c.style.display = '';
					d.style.display = '';
					e.style.display = 'none';
					f.style.display = 'none';
					break;
					case "Check Sale Resp": 
						a.style.display = 'none';
					 b.style.display = '';
					 c.style.display = 'none';
					 d.style.display = 'none';
					 e.style.display = 'none';
					 f.style.display = '';
						break;
					 case "Check Transfer Resp": 
					 	a.style.display = 'none';
					 b.style.display = '';
					 c.style.display = 'none';
					 d.style.display = 'none';
					 e.style.display = '';
					 f.style.display = '';
						 break;
	}
	}

 function sign (form) {
		//gathering the parameter values for string to sign
 var at = document.dapi_hmac_sha1.a Token.value;
 var sn = document.dapi_hmac_sha1.serial Number.value;
		var endp = document.dapi_hmac_sha1.endpoint Id.value;
		var nonce = document.dapi_hmac_sha1.session Nonce.value;
		var inv = document.dapi_hmac_sha1.invoice.value;
		var cur = document.dapi_hmac_sha1.tx Currency.value;
 var amount Info = document.get Element By Id("amount Warning");
	 var amount To Fix = document.dapi_hmac_sha1.tx Amount.value \* 100;
 var fixed Amount = amount To Fix.to Fixed(0);
 if (fixed Amount != amount To Fix)
 { amount Info.innerHTML = amount Info.innerHTML.replace("Will be calculated to centis in generated string", "Possible floating point imprecision (for more information check Floating Point Math)");}
 else {amount Info.innerHTML = amount Info.innerHTML.replace("Possible floating point imprecision (for more information check Floating Point Math)", "Will be calculated to centis in generated string");}

		var amt = fixed Amount;
		var dref = document.dapi_hmac_sha1.dest Cardref.value;
		var sref = document.dapi_hmac_sha1.source Cardref.value;
		var mkey = document.dapi_hmac_sha1.control Key.value;
		operation = document.get Element By Id('operation Name').value;

 switch (operation) {
 case "Init Verif Resp":
 string Text = at + sn + endp + nonce + inv + cur;
 get Signature (string Text);
 break;
 case "Check Verif Resp":
 string Text = sn + nonce + endp + inv;
 get Signature (string Text);
 break;
			//initiate sale response and initiate transfer response signatures are identical
 case "Init Transfer Or Sale Resp":
 string Text = at + sn + endp + nonce + inv + amt + cur;
 get Signature (string Text);
 break;
 case "Check Sale Resp":
 string Text = sn + nonce + endp + inv + sref;
 get Signature (string Text);
 break;
 case "Check Transfer Resp":
 string Text = sn + nonce + dref + endp + inv + sref;
 get Signature (string Text);
 break;
 case "Mapping Resp":
 string Text = nonce + endp + inv;
 get Signature (string Text);
 break;
 }

 //calculates signature and shows it
 function get Signature (data) {
 show Text("dapi String", data);
 hmac = CryptoJS.HmacSHA1 (data, CryptoJS.enc. Hex.parse (mkey.replace(/-/g, "")));
 show Text("dapi Signed", hmac.to String (CryptoJS.enc. Hex));
 }

 $(document).ready (function() {
 $('pre code').each (function (i, block) {
 hljs.highlight Block (block);
 });
 }); 
 return false;
 }

 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
 element.innerHTML ="";
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }

 //random values for invoice 
 function rand Inv (c) {
 document.get Element By Id (c).value = "inv" + Math.floor (Math.random()\*10000000);
 }

 //random values for nonce or access Token
 function rand Param (r) {
 document.get Element By Id (r).value = "testrandomvalue" + Math.floor (Math.random()\*1000000000000000000000);
 }
</script>

<form name="dapi_hmac_sha1">
 <select id="operation Name" class="doc-select" name="operation Name" size="1" onchange="get Params()">
 <option value="Init Verif Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Initiate Verification response signature</option>
 <option value="Check Verif Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Check Verification response signature</option>
 <option value="Init Transfer Or Sale Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Initiate Sale response signature</option>
	 <option value="Check Sale Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Check Sale response signature</option>
 <option value="Init Transfer Or Sale Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Initiate Transfer response signature</option>
	 <option value="Check Transfer Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Check Transfer response signature</option>
 <option value="Mapping Resp">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Card Mapping response signature</option>
 </select>
 
 <p></p>
 <input type="button" class="doc-button" style="font-size: 100%; padding: 2px 6px 3px 6px;" value="Get signature" onclick="sign (document.dapi_hmac_sha1)" />
 <p></p>
</form>

#### Example code and SDK

There are several solutions available on Git Hub, which were developed for integration with Payneteasy on Android and iOS platforms via DAPI.
 

### Initiate sale

#### Introduction

Initiate sale is initiated through HTTPS POST request by using [URLs](#api-url-initiate-sale) and the [parameters](#api-parameters-initiate-sale).
 
To initiate sale, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}.
 
In response Connecting Party’s server also provides information about invoice in Connecting Party’s system and endpoint in Payneteasy.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/sale/initiate-sale |

#### Request Parameters

| Parameter Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.amount Centis | Transaction amount, 1.00 EUR = 100 centis. | `Necessity`: Required `Type`: Integer |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| consumer.device.imei | Consumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| consumer.ip Addresses | Consumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Consumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|
| endpoint Id | Entry point identifier for sale transaction. | `Necessity`: Required `Type`: String |
| invoice Id | Transfer transaction identifier. | `Necessity`: Required `Type`: String |
| session | | `Necessity`: Required `Type`: **Object** |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Necessity`: Required `Type`: String |
| session.signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of the access Token, consumer.device.serial Number, endpoint Id, session.nonce, invoice Id, transaction.amount Centis and the transaction.currency. | `Necessity`: Required `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "ipAddresses": ["string"]
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "session": {
    "accessToken": "string"
  },
  "transaction": {
    "amountCentis": "integer",
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "endpointId": "string",
  "invoiceId": "string",
  "session": {
    "nonce": "string",
    "signature": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  }
}
```

### Initiate transfer

#### Introduction

Initiate transfer is initiated through HTTPS POST request by using [URLs](#api-url-initiate-transfer) and the [parameters](#api-parameters-initiate-transfer).
 
To initiate funds transfer, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}.
 
In response Connecting Party’s server also provides information about invoice in Connecting Party’s system and endpoint in Payneteasy.
 
The Connecting Party’s server may also respond with the transaction’s commission.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|--------------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/transfer/initiate-transfer |

#### Request Parameters

| Parameter Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.amount Centis | Transaction amount, 1.00 EUR = 100 centis. | `Necessity`: Required `Type`: Integer |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| consumer.device.imei | Consumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Type`: Double |
| consumer.ip Addresses | Consumer’s IP addresses. | `Type`: List |
| consumer.ip Addresses[] | Consumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |
| from Bin | Source of funds card BIN (first 6 digits of card number) may be used to display pre-calculated commission. | `Necessity`: Optional `Type`: String `Length`: 6 |
| to Bin | Destination of funds card BIN (first 6 digits of card number) may be used to display pre-calculated commission. | `Necessity`: Optional `Type`: String `Length`: 6 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------|
| endpoint Id | Entry point identifier for transfer transaction. | `Necessity`: Required `Type`: String |
| invoice Id | Transfer transaction identifier. | `Necessity`: Required `Type`: String |
| session | | `Necessity`: Required `Type`: **Object** |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Necessity`: Required `Type`: String |
| session.signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of the access Token, consumer.device.serial Number, endpoint Id, session.nonce, invoice Id, transaction.amount Centis and the transaction.currency. | `Necessity`: Required `Type`: String |
| rates | | `Necessity`: Optional `Type`: **Object** |
| rates.min | Possible minimum commission amount. | `Necessity`: Optional `Type`: String |
| rates.max | Possible maximum commission amount. | `Necessity`: Optional `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "ipAddresses": ["string"]
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "session": {
    "accessToken": "string"
  },
  "transaction": {
    "amountCentis": "integer",
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "endpointId": "string",
  "invoiceId": "string",
  "rates": {
    "min": "string",
    "max": "string"
  },
  "session": {
    "nonce": "string",
    "signature": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  }
}
```

### Initiate verification

#### Introduction

Initiate verification is initiated through HTTPS POST request by using [URLs](#api-url-initiate-verification) and the [parameters](#api-parameters-initiate-verification).
 
To initiate card verification, Connecting Party’s app sends {access Token} with other device parameters to Connecting Party’s server. These parameters are used to start a session with unique random {nonce} and encrypted {signature}. In response Connecting Party’s server also provides information about {invoice Id} in Connecting Party’s system and {endpoint Id} in Payneteasy.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|----------------------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/verification/initiate-verification |

#### Request Parameters

| Parameter Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| consumer.device.imei | Consumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| consumer.ip Addresses | Consumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Consumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| endpoint Id | Entry point identifier for verification transaction. | `Type`: String |
| invoice Id | Verification transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Type`: String |
| session.signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of access Token, consumer.device.serial Number, endpoint Id, session.nonce, invoice Id and transaction.currency. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "ipAddresses": ["string"]
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "session": {
    "accessToken": "string"
  },
  "transaction": {
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "endpointId": "string",
  "invoiceId": "string",
  "session": {
    "nonce": "string",
    "signature": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  }
}
```

### Mobile Device Payneteasy API

### Mobile Device Connecting Party Server API

### Perform sale

#### Introduction

Perform sale is initiated through HTTPS POST request by using [URLs](#api-url-perform-sale) and the [parameters](#api-parameters-perform-sale).
 
On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform sale transaction.
 
 
A lot of criteria checks and filters may be applied, such as BIN, currency, country, blacklisted or not, etc. Depending on the integration, these settings may be customizable.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------|-------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/sale/{endpoint Id}/{invoice Id} | https://gate.payneteasy.eu/paynet/dapi/v1/sale/{endpoint Id}/{invoice Id} |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| consumer.email | Сonsumer’s email address, if sent in original card mapping transaction and card reference is being used instead of cardholder data. | `Necessity`: Required `Type`: String `Length`: 3-128 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.nonce | Value received in initiate sale response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.signature | Value received in initiate sale response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| source Of Funds | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card | Only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.expiry | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.expiry.month | Source Card expiration month. | `Necessity`: Required `Type`: Integer `Length`: 2 |
| source Of Funds.card.expiry.year | Source Card expiration year. | `Necessity`: Required `Type`: Integer `Length`: 4 |
| source Of Funds.card.holder | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.holder.first Name | Cardholder’s first name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.holder.last Name | Cardholder’s last name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.holder.printed Name | Cardholder’s printed name (first and last name together). May be used instead of first Name + last Name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.number | Source card number (PAN). | `Necessity`: Required `Type`: String `Length`: 9-19 |
| source Of Funds.card.security Code | Source card security code (CVV). | `Necessity`: Required `Type`: String `Length`: 3-4 |
| source Of Funds.reference | only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| source Of Funds.reference.client Card Id | Source card reference identifier (on client side). | `Necessity`: Required `Type`: String `Length`: 1-128 |
| source Of Funds.reference.security Code | Source card security code (CVV). | `Necessity`: Required `Type`: String `Length`: 3-4 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.amount Centis | Transaction amount, 1.00 EUR = 100 centis. | `Necessity`: Required `Type`: Integer |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| billing | | `Necessity`: Optional `Type`: **Object** |
| billing.address | | `Necessity`: Optional `Type`: **Object** |
| billing.address.city | City name. | `Necessity`: Optional `Type`: String `Length`: 1-100 |
| billing.address.country | ISO alpha3 country code. | `Necessity`: Optional `Type`: String `Length`: 3 |
| billing.address.postcode Zip | ZIP post code. | `Necessity`: Optional `Type`: String `Length`: 1-10 |
| billing.address.state | State is used if present. For example, Los Angeles is in CA state. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| billing.address.street | Street is used for district names and street names. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.address.street2 | Street 2 is used for long addresses. Usually it contains apartment and building №. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.phone | Сonsumer’s contact phone number. | `Necessity`: Optional `Type`: String `Length`: 1-20 |
| consumer.birth Day | Сonsumer’s birth day in “ddMMyyyy” format. | `Necessity`: Optional `Type`: String `Length`: 8 |
| consumer.device.imei | Сonsumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| consumer.ip Addresses | Сonsumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Сonsumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |
| order | | `Necessity`: Optional `Type`: **Object** |
| order.description | Brief transaction description. May be mandatory for certain Acquirer Banks. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.site Url | URL of website associated with the transaction. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.purpose | May be used for better transaction control or additional checks. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------|----------------------------------------|------------------------------|
| invoice Id | Sale transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of sale transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `INVALID_REQUEST`, `INVALID_CONFIGURATION`, `INTERNAL_ERROR`, `PROCESSING_FAILED`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Sale transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "billing": {
    "address": {
      "city": "string",
      "country": "string",
      "postcodeZip": "string",
      "state": "string",
      "street": "string",
      "street2": "string"
    },
    "phone": "string"
  },
  "consumer": {
    "birthDay": "string",
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "email": "string",
    "ipAddresses": ["string"]
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "order": {
    "description": "string",
    "siteUrl": "string",
    "purpose": "string"
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string"
  },
  "sourceOfFunds": {
    "card": {
      "expiry": {
        "month": "integer",
        "year": "integer"
      },
      "holder":{
        "firstName": "string",
        "lastName": "string"
      },
      "number": "string",
      "securityCode": "string"
    },
    "reference": {
      "clientCardId": "string",
      "securityCode": "string"
    }
  },
  "transaction": {
    "amountCentis": "integer",
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Perform transfer

#### Introduction

Perform transfer is initiated through HTTPS POST request by using [URLs](#api-url-perform-transfer) and the [parameters](#api-parameters-perform-transfer).
 
On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform funds transfer from card to card.
 
A lot of criteria checks and filters may be applied, such as BIN, currency, country, blacklisted or not, etc. Depending on the integration, these settings may be customizable.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id} | https://gate.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id} |

#### Request Parameters

| Parameter Name | Description | Value |
|-------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| consumer.email | Сonsumer’s email address, if sent in original card mapping transaction and card reference is being used instead of cardholder data. | `Necessity`: Required `Type`: String `Length`: 3-128 |
| destination Of Funds | | `Necessity`: Required `Type`: **Object** |
| destination Of Funds.card | Only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| destination Of Funds.card.number | Destination card number (PAN). | `Necessity`: Required `Type`: String `Length`: 9-19 |
| destination Of Funds.reference | Only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| destination Of Funds.reference.client Card Id | Destination card reference identifier (on client side). | `Necessity`: Required `Type`: String `Length`: 1-128 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.nonce | Value received in Initiate transfer response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.signature | Value received in Initiate transfer response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| source Of Funds | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card | Only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.expiry | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.expiry.month | Source Card expiration month. | `Necessity`: Required `Type`: Integer `Length`: 2 |
| source Of Funds.card.expiry.year | Source Card expiration year. | `Necessity`: Required `Type`: Integer `Length`: 4 |
| source Of Funds.card.holder | | `Necessity`: Required `Type`: **Object** |
| source Of Funds.card.holder.first Name | Cardholder’s first name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.holder.last Name | Cardholder’s last name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.holder.printed Name | Cardholder’s printed name (first and last name together). May be used instead of first Name + last Name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Of Funds.card.number | Source card number (PAN). | `Necessity`: Required `Type`: String `Length`: 9-19 |
| source Of Funds.card.security Code | Source card security code (CVV). | `Necessity`: Required `Type`: String `Length`: 3-4 |
| source Of Funds.reference | only one of these subtypes (card, reference) should be used. | `Necessity`: Required `Type`: **Object** |
| source Of Funds.reference.client Card Id | Source card reference identifier (on client side). | `Necessity`: Required `Type`: String `Length`: 1-128 |
| source Of Funds.reference.security Code | Source card security code (CVV). | `Necessity`: Required `Type`: String `Length`: 3-4 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.amount Centis | Transaction amount, 1.00 EUR = 100 centis. | `Necessity`: Required `Type`: Integer |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| billing | | `Necessity`: Optional `Type`: **Object** |
| billing.address | | `Necessity`: Optional `Type`: **Object** |
| billing.address.city | City name. | `Necessity`: Optional `Type`: String `Length`: 1-100 |
| billing.address.country | ISO alpha3 country code. | `Necessity`: Optional `Type`: String `Length`: 3 |
| billing.address.postcode Zip | ZIP post code. | `Necessity`: Optional `Type`: String `Length`: 1-10 |
| billing.address.state | State is used if present. For example, Los Angeles is in CA state. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| billing.address.street | Street is used for district names and street names. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.address.street2 | Street 2 is used for long addresses. Usually it contains apartment and building №. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.phone | Сonsumer’s contact phone number. | `Necessity`: Optional `Type`: String `Length`: 1-20 |
| consumer.birth Day | Сonsumer’s birth day in “ddMMyyyy” format. | `Necessity`: Optional `Type`: String `Length`: 8 |
| consumer.device.imei | Сonsumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| consumer.ip Addresses | Сonsumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Сonsumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |
| order | | `Necessity`: Optional `Type`: **Object** |
| order.description | Brief transaction description. May be mandatory for certain Acquirer Banks. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.site Url | URL of website associated with the transaction. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.purpose | May be used for better transaction control or additional checks. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------|--------------------------------------------|------------------------------|
| invoice Id | Transfer transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of transfer transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `INVALID_REQUEST`, `INVALID_CONFIGURATION`, `INTERNAL_ERROR`, `PROCESSING_FAILED`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Transfer transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "billing": {
    "address": {
      "city": "string",
      "country": "string",
      "postcodeZip": "string",
      "state": "string",
      "street": "string",
      "street2": "string"
    },
    "phone": "string"
  },
  "consumer": {
    "birthDay": "string",
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "email": "string",
    "ipAddresses": ["string"]
  },
  "destinationOfFunds": {
    "card": {
      "number": "string",
    },
    "reference": {
      "clientCardId": "string"
    }
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "order": {
    "description": "string",
    "siteUrl": "string",
    "purpose": "string"
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string"
  },
  "sourceOfFunds": {
    "card": {
      "expiry": {
        "month": "integer",
        "year": "integer"
      },
      "holder":{
        "firstName": "string",
        "lastName": "string"
      },
      "number": "string",
      "securityCode": "string"
    },
    "reference": {
      "clientCardId": "string",
      "securityCode": "string"
    }
  },
  "transaction": {
    "amountCentis": "integer",
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Perform validation

#### Introduction

Perform validation is initiated through HTTPS POST request by using [URLs](#api-url-perform-verification) and the [parameters](#api-parameters-perform-verification).
 
Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to check the card for being valid.
 
A lot of criteria checks and filters may be applied, such as BIN, currency, country, blacklisted or not, etc. Depending on the integration, these settings may be customizable.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/verification/{endpoint Id}/{invoice Id} | https://gate.payneteasy.eu/paynet/dapi/v1/verification/{endpoint Id}/{invoice Id} |

#### Request Parameters

| Parameter Name | Description | Value |
|-------------------------------|--------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| consumer.email | Сonsumer’s email address. | `Necessity`: Required `Type`: String `Length`: 3-128 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.nonce | Value received in Initial verification response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.signature | Value received in Initial verification response. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| source Card | | `Necessity`: Required `Type`: **Object** |
| source Card.expiry | | `Necessity`: Required `Type`: **Object** |
| source Card.expiry.month | Source Card expiration month. | `Necessity`: Required `Type`: Integer `Length`: 2 |
| source Card.expiry.year | Source Card expiration year. | `Necessity`: Required `Type`: Integer `Length`: 4 |
| source Card.holder | | `Necessity`: Required `Type`: **Object** |
| source Card.holder.first Name | Cardholder’s first name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Card.holder.last Name | Cardholder’s last name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Card.holder.printed Name | Cardholder’s printed name (first and last name together). May be used instead of first Name + last Name. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| source Card.number | Source card number (PAN). | `Necessity`: Required `Type`: String `Length`: 9-19 |
| source Card.security Code | Source card security code (CVV). | `Necessity`: Required `Type`: String `Length`: 3-4 |
| transaction | | `Necessity`: Required `Type`: **Object** |
| transaction.currency | Upper case letters (ISO 4217 alpha code). | `Necessity`: Required `Type`: String `Length`: 3 |
| location | | `Necessity`: Optional `Type`: **Object** |
| location.lat | The latitude specified in the range of -90.0 through +90.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| location.lng | The longitude specified in the range -180.0 through +180.0, both inclusive. | `Necessity`: Optional `Type`: Double |
| billing | | `Necessity`: Optional `Type`: **Object** |
| billing.address | | `Necessity`: Optional `Type`: **Object** |
| billing.address.city | City name. | `Necessity`: Optional `Type`: String `Length`: 1-100 |
| billing.address.country | ISO alpha3 country code. | `Necessity`: Optional `Type`: String `Length`: 3 |
| billing.address.postcode Zip | ZIP post code | `Necessity`: Optional `Type`: String `Length`: 1-10 |
| billing.address.state | State is used if present. For example, Los Angeles is in CA state. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| billing.address.street | Street is used for district names and street names. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.address.street2 | Street 2 is used for long addresses. Usually it contains apartment and building №. | `Necessity`: Optional `Type`: String `Length`: 1-50 |
| billing.phone | Customer’s contact phone number. | `Necessity`: Optional `Type`: String `Length`: 1-20 |
| consumer.birth Day | Сonsumer’s birth day in “ddMMyyyy” format. | `Necessity`: Optional `Type`: String `Length`: 8 |
| consumer.device.imei | Сonsumer’s device international mobile equipment identity. | `Necessity`: Optional `Type`: String `Length`: 14-16 |
| consumer.ip Addresses | Сonsumer’s IP addresses. | `Necessity`: Optional `Type`: List |
| consumer.ip Addresses[] | Сonsumer’s IP address. | `Necessity`: Optional `Type`: String `Length`: 7-15 |
| order | | `Necessity`: Optional `Type`: **Object** |
| order.description | Brief transaction description. May be mandatory for certain Acquirer Banks. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.site Url | URL of website associated with the transaction. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order.purpose | May be used for better transaction control or additional checks. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------|------------------------------|
| invoice Id | Verification transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of verification transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `INVALID_REQUEST`, `INVALID_CONFIGURATION`, `INTERNAL_ERROR`, `PROCESSING_FAILED`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Verification transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "billing": {
    "address": {
      "city": "string",
      "country": "string",
      "postcodeZip": "string",
      "state": "string",
      "street": "string",
      "street2": "string"
    },
    "phone": "string"
  },
  "consumer": {
    "birthDay": "string",
    "device": {
      "imei": "string",
      "serialNumber": "string"
    },
    "email": "string",
    "ipAddresses": ["string"]
  },
  "location": {
    "lat": "double",
    "lng": "double"
  },
  "order": {
    "description": "string",
    "siteUrl": "string",
    "purpose": "string"
  },
  "session": {
    "accessToken": "string",
    "nonce": "string",
    "signature": "string"
  },
  "sourceCard": {
    "expiry": {
      "month": "integer",
      "year": "integer"
    },
    "holder":{
      "firstName": "string",
      "lastName": "string"
    },
    "number": "string",
    "securityCode": "string"
  },
  "transaction": {
    "currency": "string"
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Sale card mapping notification

#### Introduction

Sale card mapping notification is initiated through HTTPS POST request by using [URLs](#api-url-sale-card-mapping-notification) and the [parameters](#api-parameters-sale-card-mapping-notification).
 
Card mapping notification is used to allow Consumer credentials (phone, email, billing address, twitter name, etc) for mapping to card data. Card mappings can be used later in transfer or sale transactions instead of card numbers and other cardholder information. Payneteasy sends Sale card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}.
 
Connecting Party’s server maps this {server Card Id} to {client Card Id}, created on its side. This {client Card Id} can then be mapped in Connecting Party’s app or on Connecting Party’s server to any Consumer’s data from the initial Perform sale request. This allows Connecting Party’s app to process sale or transfer transactions by Consumer’s email, phone number, etc.
 
{unique Reference Card Id} remains the same if Consumer makes another transaction with the same card number but different expiry date, for example. It can be used by Connecting Party for loyalty programs or fraud control.
 
Connecting Party’s app makes new sale requests using {client Card Id} instead of source card data. Payneteasy sends this {client Card Id} to Connecting Party’s server in “Check sale request” and gets mapped to it {server Card Id} in “Check sale response” from Connecting Party’s server, which is used to continue the processing of this transaction.
 
{server Card Id} of source or verified card can be used for new sale transactions and both as source or destination for new transfer transactions.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|-----------------------------------------------------------|
| https://proxy.connectingpartyserver.com/sale/notification |

#### Request Parameters

| Parameter Name | Description | Value |
|--------------------------------------------|--------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Consumer’s access token key. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.token | The session token of sale transaction. | `Necessity`: Required `Type`: String `Length`: 16-36 |
| source Card | | `Necessity`: Optional `Type`: **Object** |
| source Card.bin | The Source card BIN. | `Necessity`: Optional `Type`: Integer |
| source Card.reference | | `Necessity`: Optional `Type`: **Object** |
| source Card.reference.server Card Id | The Source card reference identifier (on server side). | `Necessity`: Optional `Type`: String `Length`: 1-64 |
| source Card.reference.unique Reference Card Id | The Source card unique identifier (on server side). | `Necessity`: Optional `Type`: Integer |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| invoice Id | Sale transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of session.nonce, endpoint Id and invoice Id. | `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Type`: String |
| session.token | The session token of sale transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Сause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Sale transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "session": {
    "accessToken": "string",
    "token":"string"
  },
  "sourceCard": {
    "bin": "integer",
    "reference": {
      "serverCardId": "string",
      "uniqueReferenceCardId": "integer"
    }
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Sale status

#### Introduction

Sale status is initiated through HTTPS POST request by using [URLs](#api-url-sale-status) and the [parameters](#api-parameters-sale-status).
 
Sale status request is made by Connecting Party’s app to Payneteasy to get the status of sale transaction.
 
It is recommended to send Sale status request for a period of 2-3 minutes with interval of 3-5 seconds between requests. Connecting Party’s server should rely on the callback for final status.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/sale/{endpoint Id}/{invoice Id}/status | https://gate.payneteasy.eu/paynet/dapi/v1/sale/{endpoint Id}/{invoice Id}/status |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------|---------------------------------------------------------|
| session | | `Type`: **Object** |
| session.access Token | The access token key received in Optional consumer authentication. | `Type`: String `Length`: 32-128 |
| session.token | The session token of sale transaction. | `Type`: String `Length`: 16-36 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| invoice Id | Sale transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of sale transaction | `Type`: String |
| state | Possible values: `PROCESSING`, `REDIRECT_REQUEST`, `APPROVED`, `DECLINED`. | `Type`: Enum |
| bank Order Id | Required if state is `APPROVED` or `DECLINED`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| redirect Url | Required if state is `REDIRECT_REQUEST`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| order Id | Order identifier in payment processing system. | `Necessity`: Conditional `Type`: String |
| transaction | | `Necessity`: Conditional `Type`: **Object** |
| transaction.amount Centis | Amount of money transfered in centis, 1.00 EUR = 100 centis. | `Necessity`: Conditional `Type`: Integer |
| transaction.commission Centis | Amount of commission held in centis (depends on the integration). | `Necessity`: Conditional `Type`: Integer |
| transaction.order Created Date | Order creation date in payment processing system. | `Necessity`: Conditional `Type`: String |
| transaction.transaction Created Date | Transaction creation date in payment processing system. | `Necessity`: Conditional `Type`: String |
| error Code | Decline reason code, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: Integer |
| error Message | Decline reason message, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: String `Length`: 128 |
| secure3DAuth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`, `UNSUPPORTED`, `UNSUPPORTED` means that card does not support 3-D Secure or 3DS authentication process finished with an unknown status. | `Necessity`: Optional `Type`: Enum |
| random Sum Auth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`. | `Necessity`: Optional `Type`: Enum |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `INTERNAL_ERROR`, `PROCESSING_FAILED`, `ORDER_NOT_FOUND`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Sale transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "session": {
    "accessToken": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "bankOrderId": "string",
  "invoiceId": "string",
  "redirectUrl": "string",
  "session": {
    "token": "string"
  },
  "state": "enum"
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Transfer card mapping notification

#### Introduction

Transfer card mapping notification is initiated through HTTPS POST request by using [URLs](#api-url-transfer-card-mapping-notification) and the [parameters](#api-parameters-transfer-card-mapping-notification).
 
Card mapping notification is used to allow Consumer credentials (phone, email, billing address, twitter name, etc) for mapping to card data. Card mappings can be used later in transfer or sale transactions instead of card numbers and other cardholder information. Payneteasy sends Transfer card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}.
 
Connecting Party’s server maps this {server Card Id} to {client Card Id}, created on its side. This {client Card Id} can then be mapped in Connecting Party’s app or on Connecting Party’s server to any Consumer’s data from the initial Perform transfer request. This allows Connecting Party’s app to process sale or transfer transactions by Consumer’s email, phone number, etc.
 
{unique Reference Card Id} remains the same if Consumer makes another verification with the same card number but different expiry date, for example. It can be used by Connecting Party for loyalty programs or fraud control.
 
Connecting Party’s app makes new transfer requests using {client Card Id} instead of source or destination card data. Payneteasy sends this {client Card Id} to Connecting Party’s server in “Check transfer request” and gets mapped to it {server Card Id} in “Check transfer response” from Connecting Party’s server, which is used to continue processing the transfer transaction.
 
{server Card Id} of source or verified card can be used both as source or destination for new transfer and sale transactions; {server Card Id} of destination card can be used only as destination for new transfers.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|---------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/transfer/notification |

#### Request Parameters

| Parameter Name | Description | Value |
|-------------------------------------------------|-------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| consumer | | `Necessity`: Required `Type`: **Object** |
| consumer.device | | `Necessity`: Required `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Necessity`: Required `Type`: String `Length`: 1-50 |
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | Consumer’s access token key. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.token | The session token of transfer transaction. | `Necessity`: Required `Type`: String `Length`: 16-36 |
| destination Card | | `Necessity`: Optional `Type`: **Object** |
| destination Card.bin | The Destination card BIN. | `Necessity`: Optional `Type`: Integer |
| destination Card.reference | | `Necessity`: Optional `Type`: **Object** |
| destination Card.reference.server Card Id | The Destination card reference identifier (on server side). | `Necessity`: Optional `Type`: String `Length`: 1-64 |
| destination Card.reference.unique Reference Card Id | The Destination card unique identifier (on server side). | `Necessity`: Optional `Type`: Integer |
| source Card | | `Necessity`: Optional `Type`: **Object** |
| source Card.bin | The Source card BIN. | `Necessity`: Optional `Type`: Integer |
| source Card.reference | | `Necessity`: Optional `Type`: **Object** |
| source Card.reference.server Card Id | The Source card reference identifier (on server side). | `Necessity`: Optional `Type`: String `Length`: 1-64 |
| source Card.reference.unique Reference Card Id | The Source card unique identifier (on server side). | `Necessity`: Optional `Type`: Integer |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| invoice Id | Transfer transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of session.nonce, endpoint Id and invoice Id. | `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Type`: String |
| session.token | The session token of transfer transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Сause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Transfer transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "destinationCard": {
    "bin": "integer",
    "reference": {
      "serverCardId": "string",
      "uniqueReferenceCardId": "integer"
      }
    },
  "session": {
    "accessToken": "string",
    "token":"string"
  },
  "sourceCard": {
    "bin": "integer",
    "reference": {
      "serverCardId": "string",
      "uniqueReferenceCardId": "integer"
    }
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Transfer status

#### Introduction

Transfer status is initiated through HTTPS POST request by using [URLs](#api-url-transfer-status) and the [parameters](#api-parameters-transfer-status).
 
Funds transfer status request is made by Connecting Party’s app to Payneteasy to get the status of transfer transaction.
 
It is recommended to send Transfer status request for a period of 2-3 minutes with interval of 3-5 seconds between requests. Connecting Party’s server should rely on the callback for final status.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id}/status | https://gate.payneteasy.eu/paynet/dapi/v1/transfer/{endpoint Id}/{invoice Id}/status |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------|---------------------------------------------------------|
| session | | `Type`: **Object** |
| session.access Token | The access token key received in Optional consumer authentication. | `Type`: String `Length`: 32-128 |
| session.token | The session token of transfer transaction. | `Type`: String `Length`: 16-36 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| invoice Id | Transfer transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of transfer transaction. | `Type`: String |
| state | Possible values: `PROCESSING`, `REDIRECT_REQUEST`, `APPROVED`, `DECLINED`. If Consumer defined transfer rates enable get `TRANSFER_FEE_REQUEST`. | `Type`: Enum |
| bank Order Id | Required if state is `APPROVED` or `DECLINED`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| redirect Url | Required if state is `REDIRECT_REQUEST`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| order Id | Order identifier in payment processing system. | `Necessity`: Conditional `Type`: String |
| transaction | | `Necessity`: Conditional `Type`: **Object** |
| transaction.amount Centis | Amount of money transfered in centis, 1.00 EUR = 100 centis. | `Necessity`: Conditional `Type`: Integer |
| transaction.commission Centis | Amount of commission held in centis. | `Necessity`: Conditional `Type`: Integer |
| transaction.order Created Date | Order creation date in payment processing system. | `Necessity`: Conditional `Type`: String |
| transaction.transaction Created Date | Transaction creation date in payment processing system. | `Necessity`: Conditional `Type`: String |
| error Code | Decline reason code, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: Integer |
| error Message | Decline reason message, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: String `Length`: 128 |
| secure3DAuth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`, `UNSUPPORTED` means that card does not support 3-D Secure or 3DS authentication process finished with an unknown status. | `Necessity`: Optional `Type`: Enum |
| random Sum Auth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`. | `Necessity`: Optional `Type`: Enum |

#### Success Response Parameters for Consumer defined transfer rates

Transfer status response includes the state parameter with TRANSFER_FEE_REQUEST value and the transfer Fee List object with a list of commissions for possible processing gates. Each processing gate is represented by it’s own aliased name in assigned Id parameter. TRANSFER_FEE_REQUEST value in state parameter exists only in “Consumer defined transfer rates” flow.
 
When the transaction reaches TRANSFER_FEE_REQUEST state, the processing will remain paused until Complete transfer request is sent.
 

| Parameter Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| transfer Fee List | | `Type`: **Object** |
| transfer Fee List.assigned Id | Aliased payment gateway name. | `Type`: String |
| transfer Fee List.commission Centis | Amount of commission to be held in centis, 1.00 EUR = 100 centis. | `Type`: Integer |
| transfer Fee List.currency | Upper case letters (ISO 4217 alpha code). | `Type`: String |
| state | In addition to the values from [Status Transfer](#api-transfer-status), `TRANSFER_FEE_REQUEST` value only exists in this flow. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `INTERNAL_ERROR`, `PROCESSING_FAILED`, `ORDER_NOT_FOUND`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Transfer transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "session": {
    "accessToken": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "bankOrderId": "string",
  "invoiceId": "string",
  "redirectUrl": "string",
  "session": {
    "token": "string"
  },
  "state": "enum"
}
```

#### Success Response Example for Consumer defined transfer rates

 
**The following structure extends the default Transfer status response body (e.g. 2 processing gates):**
 
 
```json
{
  "bankOrderId": "string",
  "invoiceId": "string",
  "redirectUrl": "string",
  "session": {
    "token": "string"
  },
  "state": "TRANSFER_FEE_REQUEST",
  "transferFeeList": [
    {
      "assignedId": "string",
      "commissionCentis": "integer",
      "currency": "string"
    },
    {
      "assignedId": "string",
      "commissionCentis": "integer",
      "currency": "string"
    }
  ]
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### API Use-Cases

### /api/v2/account-verification-form

#### Introduction

Account Verification form is initiated through HTTPS POST request by using [URLs](#api-url-account-verification-form) and the [parameters](#api-v2-account-verification-form-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/account-verification-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/account-verification-form/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/account-verification-form/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/account-verification-form/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Leading and trailing whitespace in input parameters will be omitted.
 
Acquirer can redefine the necessity of some fields so they become required instead of optional.
 

| Request parameter name | Description | Value |
|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-url-account-verification-form)) 2. Request parameter: client_orderid 3. Request parameter: email 4. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Payer’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Payer’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| currency | Currency the transaction is charged in (three-letter currency code). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Optional `Type`: String `Length`: 3 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined or in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters which come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either redirect_url or a combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters which come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either redirect_url or a combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters which come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either redirect_url or a combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |
| preferred_language | Payer’s [two-letter language code](https://doc.payneteasy.com/integration/reference/language_codes.html.md) for multi-language payment-forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent as this parameter value are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-form-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| payet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| redirect-url | The URL to the page where the Connecting Party should redirect the Payer’s browser. Connecting Party should send HTTP 302 redirect, see [Account Verification Form Flow](https://doc.payneteasy.com/integration/api_use_cases/account_verification_form.html.md). |

#### Request Example

```http
POST /paynet/api/v2/account-verification-form/39915 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 565
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=34T43R77N
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&email=john.smith@gmail.com
&ipaddress=65.153.12.232
&site_url=www.google.com
&currency=USD
&purpose=user_account1
&redirect_url=http://connectingparty.com/result
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&merchant_form_data=testparam%3Dtest1%26mynewparam%3Dtest2
&control=5112b51084be33fa331d995d17b9d82af3bfbbc9
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 10 May 2023 09:07:27 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002e378e8
&merchant-order-id=34T43R77N
&paynet-order-id=6998044
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A5538374E4535734B44743364784335716A7979316B673D
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 22 May 2023 11:36:59 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 152

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e5c587
&merchant-order-id=34T43R77N
&error-message=INVALID_CONTROL_CODE
&error-code=2
```

##### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/account-verification-form/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/account-verification

#### Introduction

Account Verification is initiated through HTTPS POST request by using [URLs](#api-url-account-verification-url) and the [parameters](#api-url-account-verification-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/account-verification/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/account-verification/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/account-verification/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/account-verification/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Acquirer can redefine the necessity of some fields so they become required instead of optional.
 
Leading and trailing whitespace in input parameters will be omitted.
 

> **Warning:** The following characters must be escaped in the parameter values: & + “.

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| cvv2 | Payer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card. | `Necessity`: Required `Type`: Numeric `Length`: 3-4 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-url-account-verification-url)) 2. Request parameter: client_orderid 3. Request parameter: email 4. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Payer’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Payer’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| cardrefid | Card reference ID obtained at [Card Registration Stage](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| credit_card_number | Payer’s credit card number. Send either combination of credit_card_number, card_printed_name, expire_month and expire_year or cardrefid, not all. | `Necessity`: Conditional `Type`: Numeric `Length`: 20 |
| card_printed_name | Cardholder name, printed on the bank card. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire_month | Bank card expiration month. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| expire_year | Bank card expiration year. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Partys who let their Payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/account-verification/39915 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 527
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=34T43R77N
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&email=john.smith@gmail.com
&ipaddress=65.153.12.232
&site_url=www.google.com
&credit_card_number=4666034752545240
&card_printed_name=CARD HOLDER
&expire_month=12
&expire_year=2099
&cvv2=123
&purpose=user_account1
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&control=5112b51084be33fa331d995d17b9d82af3bfbbc9
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 27 Apr 2023 14:03:58 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 145

type=async-response
&serial-number=00000000-0000-0000-0000-000002e34518
&merchant-order-id=34T43R77N
&paynet-order-id=6994016
&end-point-id=39915
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 22 May 2023 11:14:25 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 152

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e5c583
&merchant-order-id=34T43R77N
&error-message=INVALID_CONTROL_CODE
&error-code=2
```

##### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/account-verification/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/documents/add-document

#### Introduction

Add document is initiated through HTTPS POST request by using [URL](#api-url-add-document) and the [parameters](#request-parameters-add-document) specified below. [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) is used for authentication (two-legged mode).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration Base URL | Production Base URL |
|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/documents/add-document/ENDPOINTID/ORDERID | https://gate.payneteasy.eu/paynet/api/v2/documents/add-document/ENDPOINTID/ORDERID |

#### Request Headers

| Content-Type | The request must contain this header with the following value: binary/octet-stream. |
|----------------|-----------------------------------------------------------------------------------------------------------------------------------------|
| Content-Length | This header specifies correct file size in bytes. |
| Authorization | [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) is used for authentication (two-legged mode). |

#### Request Parameters

| Request parameters | Description | Value |
|----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| endpoint id | Endpoint of the order. This parameter is passed in request URL. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| order id | Transaction order identifier assigned by Payment Gateway. This parameter is passed in request URL. | `Necessity`: Required `Type`: String `Length`: 128 |
| consumer key | Connecting Party’s login name. This parameter is used to calculate signature and is passed in Authorization request header as oauth_consumer_key. | `Necessity`: Required `Type`: String `Length`: 20 |
| consumer secret | Connecting Party’s control key. This parameter is used to calculate signature as a part of Encryption key for OAuth HMAC-SHA1. | `Necessity`: Required `Type`: String `Length`: 40 |
| file name | Name of the file to upload, e.g. filename.txt. This parameter is passed in the request body as file and in a query part of request URL as file Name. | `Necessity`: Required `Type`: String `Length`: 255 |
| comment. | Adds a comment to attached file, accessible via pointing cursor on file in order details page. This parameter is passed in a query part of request URL. | `Necessity`: Optional `Type`: String `Length`: 255 |
| file content | Field for the contents of the file. Used to calculate only txt files via bytes per symbol. Use either file content or a combination of file sha1 and file size, not both. Mandatory, if file sha1 and file size fields are empty. This parameter is passed in the request body as a string. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| file sha1 | Calculate sha1 of the file and insert here. Use either file content or a combination of file sha1 and file size, not both. Mandatory, if file content field is empty. This parameter is passed in base part of request URL, after order id parameter. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| file size | Field for file size in bytes. Use either file content or a combination of file sha1 and file size, not both. Mandatory, if file content field is empty. This parameter is passed in Content-Length request header. | `Necessity`: Conditional `Type`: String `Length`: 255 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------|
| status | May have values such as: success or error. Success means that document attached to order successfully. Error provides error-message. |
| error-message | If status is error this parameter contains the reason for decline or error details. |

#### Request Example

```http
POST /paynet/api/v2/documents/add-document/6655/1852755/561d839dde5ae8deeced73c14902e04dc746bfc2?fileName=test5.txt&comment=no%20comments HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Type: binary/octet-stream
Content-Length: 7
Authorization: OAuth realm="",oauth_signature_method="HMAC-SHA1",oauth_signature="ItDxdBQtPRqLiKTAOdy%2BAtDB5cI%3D"
Connection: close
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 18 Jul 2023 06:10:27 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 14
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000

status=success
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 18 Jul 2023 07:37:34 GMT
Content-Type: text/plain;charset=utf-8
Content-Length: 46
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000

status=error
&error-message=File+hash+mismatch
```

### /api/v2/auth-cash

#### Introduction

Auth-cash is initiated through HTTPS POST request by using [URLs](#api-v2-auth-cash-url) and the [parameters](#api-v2-auth-cash-request-parameters-url) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------|---------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/auth-cash/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/auth-cash/ENDPOINTID |

#### Request Parameters

| Parameter Name | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](https://doc.payneteasy.com/integration/api_v2_preauth-form.html.md)). 2. Request parameter: client_orderid. 3. Request parameter: amount (in minor units). 4. Request parameter: email. 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| first_name | Payer’s first name. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. (two-letter state code). Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined or in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc2.codetime.net if there is no need to redirect Payer anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| ssn | Last four digits of the Payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Payer’s two-letter language code for multi-language invoices. | `Necessity`: Optional `Type`: String `Length`: 2 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| end-point-id | Endpoint id used for the transaction. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/auth-cash/46760 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 592
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=inv3982750
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&amount=55
&email=john.smith@gmail.com
&currency=USD
&ipaddress=65.153.12.232
&site_url=https://doc2.codetime.net
&purpose=user_account1
&redirect_url=http://sandbox.payneteasy.eu/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&control=ce2dcc2b307c123242b9867cb0ce15617b8ee7f9
&preferred_language=en
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 14 Jun 2023 08:43:52 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 146

type=async-response
&serial-number=00000000-0000-0000-0000-000002eb1adf
&merchant-order-id=inv3982750
&paynet-order-id=7174243
&end-point-id=46760
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 14 Jun 2023 08:43:52 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 146

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb0d4
&error-message=Project+with+currency+RUB+does+not+apply+request+with+currency+USD
&error-code=16
```

### /api/v2/bank-wire-transfer

#### Introduction

Bank wire transfer is initiated through HTTPS POST request by using [URLs](#api-v2-bank-wire-transfer-request-url) and the [parameters](#api-v2-bank-wire-transfer-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------|------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/bank-wire-transfer/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/bank-wire-transfer/ENDPOINTID |

#### Request Parameters

| Parameter Name | Description | Value |
|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| payer-fullname | Payer’s full name. | `Necessity`: Required `Type`: String `Length`: 128 |
| recipient-account-number | Receiver\`s account number. | `Necessity`: Required `Type`: Numeric `Length`: 20 |
| recipient-bank-bic | Receiver\`s Bank Identifier Code. | `Necessity`: Required `Type`: Numeric `Length`: 9 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| payer-email | Payer’s e-mail address. | `Necessity`: Optional `Type`: String `Length`: 128 |
| payer-phone | Payer’s full international phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 128 |
| recipient-name | Receiver\`s name. | `Necessity`: Required `Type`: String `Length`: 255 |
| recipient-inn | Receiver\`s Taxpayer Identification Number. | `Necessity`: Required `Type`: String `Length`: 255 |
| payment-details | Payment purpose. | `Necessity`: Required `Type`: String `Length`: 120 |
| vat-amount | Value-added tax amount. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| payer-identity-document | Type, series and number of the identification card. | `Necessity`: Required `Type`: String `Length`: 64 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID (See: [Request URL](#api-v2-bank-wire-transfer-request-url)) 2. Request parameter: client_orderid 4. Request parameter: payer-fullname 8. Request parameter: recipient-name 5. Request parameter: recipient-account-number 6. Request parameter: recipient-bank-bic 7. Request parameter: amount (in minor units) 9. Request parameter: vat-amount (in minor units) 3. Request parameter: currency 10. merchant_control (Control key assigned to Connecting Party in Payment Gateway.) | `Necessity`: Required `Type`: String `Length`: 40 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter name | Description |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-form-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is declined or error this parameter contains the reason for decline or error details. |
| error-code | The error code in case of declined or error status. |

#### Request Example

```http
POST /paynet/api/v2/bank-wire-transfer/40265 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 436
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=902B4FF5
&payer-fullname=Test full name
&recipient-name=Test name
&recipient-account-number=40963810202157880527
&recipient-bank-bic=44030861
&amount=55.55
&vat-amount=4.54
&currency=EUR
&payer-email=john.smith@gmail.com
&payer-phone=+74951129876
&recipient-inn=7812013775
&payment-details=Test payment
&payer-identity-document=01,9207123123
&server_callback_url=https://httpstat.us/200
&control=bc7dae1fe9389aa02471c7c93d08d6b1ba0f2ea8
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 26 May 2023 11:44:12 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 145

type=async-response
&serial-number=00000000-0000-0000-0000-000003c3994f
&merchant-order-id=inv9157586
&paynet-order-id=1824084
&end-point-id=6655
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 26 May 2023 10:11:58 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 163

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e73881
&merchant-order-id=902B4FF5
&error-message=Project+with+currency+USD+does+not+apply+request+with+currency+EUR
&error-code=20
```

### /api/v2/capture

#### Introduction

Capture is initiated through HTTPS POST request to the [URLs](#api-v2-capture-request-url) and the [parameters](#api-v2-capture-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. Capture may only be initiated when Preauth have final success status. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------|------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/capture/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/capture/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/capture/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/capture/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Request Parameter | Description |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| login | Connecting Party login name. |
| client_orderid | Connecting Party order identifier of the transaction for which the status is requested. |
| orderid | Order id assigned to the order by Payneteasy |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. This parameter may or may not be sent. |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. This parameter may or may not be sent. |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login. 2. Request parameter: merchant-order-id. 3. Request parameter: paynet-order-id. 4. Request parameter: amount in minor units (if sent). 5. request parameter: currency (if amount sent) 6. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameter | Description |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| end-point-id | Endpoint id used for the transaction. |

#### Request Example

```http
POST /paynet/api/v2/capture/39914 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 119
Content-Type: application/x-www-form-urlencoded
Connection: close

login=TestMerchant
&client_orderid=902B4FF5
&orderid=6863088
&amount=345
&currency=USD
&control=da832c0fcff0105728e26465d5f99e6f83179a45
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 13:15:19 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 140

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddb06a
&merchant-order-id=902B4FF5
&paynet-order-id=6863088
&end-point-id=37211
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 12:59:09 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

pe=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb06b
&error-message=Can+not+make+capture+for+order+state+AUTH_3D_VALIDATING
&error-code=27
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/capture/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/create-card-ref

#### Introduction

Card reference ID creation is initiated through HTTPS POST request by using [URLs](#api-v2-card-ref-id-request-url) and the [parameters](#card-ref-id-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/create-card-ref/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/create-card-ref/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/create-card-ref/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/create-card-ref/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Get Card Ref Request Parameters | Description |
|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| login | Connecting Party’s login name. |
| client_orderid | Connecting Party’s order identifier of the transaction. |
| orderid | Transaction order identifier assigned by Payment Gateway. |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login 2. Request parameter: client_orderid 3. Request parameter: orderid 4. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). |

Connecting Party has to supply orderid and client_orderid associated with the first payment transaction. It emphasizes that the first payment is a mandatory step to process recurring payments. To authorize the credit card the information about it must be sufficient and an initial payment must be in [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md).

The returned Recurring Payment ID and/or Card Reference ID is a token that refers to cardholder data stored on Payment Gateway side. See the required API command to find which type of token is supported in request parameters. This ID has the following usage:
1. In direct API commands it can be passed instead of cardholder data to initiate new transaction.
2. In form API commands it can be passed to prefill the payment form with previously saved cardholder data.

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Registration Response Parameters | Description |
|------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| card-ref-id | Card reference ID to used in subsequent recurring payments. |
| unq-card-ref-id | Unique card reference ID to each PAN. It can be used by Connecting Party for loyalty programs or fraud control. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| error-message | If status is declined or error this parameter contains the reason for decline. |
| error-code | The error code is case of declined or error status. |

#### Request Example

```http
POST /paynet/api/v2/create-card-ref/46750 HTTP/1.1
Host: https://sandbox.payneteasy.eu
User-Agent: curl/7.85.0
Accept: */*
Content-Length: 100
Content-Type: application/x-www-form-urlencoded
Connection: close

login=login
&client_orderid=902B4FF5
&orderid=6937242
&control=717349cab3fcab2c13c93ff5770ae07a7b8e0727
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 07 Feb 2023 08:46:24 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 144

type=create-card-ref-response
&serial-number=00000000-0000-0000-0000-000002e110a2
&card-ref-id=1461670
&unq-card-ref-id=2463777
&status=approved
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 07 Feb 2023 08:55:26 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 123

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e110ad
&error-message=INVALID_CONTROL_CODE
&error-code=2
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/create-card-ref/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/get-card-info

#### Introduction

For integration purposes use staging environment HTTPS POST request to the [URLs](#api-v2-get-card-info-request-url) and the [parameters](#api-v2-get-card-info-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/get-card-info/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/get-card-info/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/get-card-info/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/get-card-info/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| login | Connecting Party’s login name. | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| cardrefid | Card reference ID obtained at [Card Registration Stage](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login 2. Request parameter: cardrefid 3. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Mandatory `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Information Response Parameters | Description |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be get-card-info-response, validation-error, error. If type equals error, error-message and error-code parameters contain error details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| card-printed-name | Card holder’s name. |
| bin | Bank Identification Number. |
| last-four-digits | The last four digits of PAN. |
| expire-year | Card expiration year. |
| expire-month | Card expiration month. |
| result-3d | 3DS completion result. |
| error-message | If status is validation-error or error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of validation-error or error status. |

#### Request Example

```http
POST /paynet/api/v2/get-card-info/46750 HTTP/1.1
Host: https://sandbox.payneteasy.eu
User-Agent: curl/7.85.0
Accept: */
Content-Length: 77
Content-Type: application/x-www-form-urlencoded
Connection: close

&login=Test
&cardrefid=1461665
&control=f8ffd7dac9e334799862da0e9190387510d43ff7
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 11:21:39 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 193

type=get-card-info-response
&serial-number=00000000-0000-0000-0000-000002e0d218
&card-printed-name=CARD+HOLDER
&bin=453897
&last-four-digits=6732
&expire-year=2099
&expire-month=12
&result-3d=F
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 11:26:22 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 136

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e0d21f
&error-message=End+point+with+id+99999+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/get-card-info/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/get-exchange

#### Introduction

Get exchange rate is initiated through HTTPS POST request by using [URLs](#api-v2-get-exchange-request-url) and the [parameters](#api-v2-get-exchange-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------|------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/get-exchange/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/get-exchange/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|-----------------------------|------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| exchange-provider | Exchange provider. | `Necessity`: Required `Type`: String `Length`: 128 |
| exchange-currency-code-from | Currency code that need to exchange (See:[Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). | `Necessity`: Required `Type`: String `Length`: 128 |
| exchange-currency-code-to | Currency code that need to get (See:[Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). | `Necessity`: Required `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter Name | Description |
|--------------------|-----------------------|
| exchange-low-rate | Provider’s buy rate. |
| exchange-high-rate | Provider’s sell rate. |

#### Request Example

```http
POST /paynet/api/v2/get-exchange/39790 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1684995901",oauth_nonce="1kKy3hMlAe1",oauth_signature_method="HMAC-SHA1",oauth_signature="jGUaNFqLvBO1gGgWag%2FSU3wMnUc%3D"
Content-Length: 222
Content-Type: application/x-www-form-urlencoded
Connection: close

exchange-currency-code-from=USD
&exchange-currency-code-to=RUB
&exchange-provider=test
&oauth_consumer_key=test_merch
&oauth_nonce=1kKy3hMlAe1
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1684995901
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 25 May 2023 06:27:46 GMT
Content-Length: 48
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

exchange-low-rate=10.00
&exchange-high-rate=20.00
```

#### Fail Response Example

```http
HTTP/1.1 403
Server: server
Date: Thu, 25 May 2023 07:02:59 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

error-message=Book TCurrencyBook was not found by code USB
```

### /api/v2/get-balance

#### Introduction

Get Balance is initiated through HTTPS POST request by using [URLs](#api-v2-get-balance-request-url) and the [parameters](#api-v2-get-balance-request-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). Also can be viewed on UI. Please contact support managers to enable this feature.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------|-----------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/get-balance/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/get-balance/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|------------------|------------------------------|------------------------------------------------------------------------------------------|
| balance-provider | Input your balance provider. | `Necessity`: Required `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------|
| balance-amount | Current balance. |

#### Request Example

```http
POST /paynet/api/v2/get-balance/ HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="balance_test_merchant14",oauth_signature_method="HMAC-SHA1",oauth_signature="hSXMSUPP%2FIGYOOWpU4LVx0mu7SA%3D"
Content-Length: 108
Content-Type: application/x-www-form-urlencoded
Connection: close

balance-provider=Test
&oauth_consumer_key=balance_test_merchant14
&oauth_nonce=2xGTFuAgetE
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1686923599
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 16 May 2023 08:06:05 GMT
Content-Length: 192
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

[
  {
    "balance-amount":29.99,
  }
]
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 16 Jun 2023 13:53:43 GMT
Content-Length: 42
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

error-message=Unknown balance provider saa
```

### /api/v2/get-balance/manager

#### Introduction

Get Balance by Manager is initiated through HTTPS POST request by using [URLs](#api-v2-get-balance-manager-request-url) and the [parameters](#api-v2-get-balance-manager-request-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). Also can be viewed on UI. Please contact technical support to enable this feature.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------------|---------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/get-balance/manager/MANAGERLOGIN | https://gate.payneteasy.eu/paynet/api/v2/get-balance/manager/MANAGERLOGIN |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| balance-name | Balance name. If this parameter is omitted, the result will give all available balances. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|------------------------------|-------------------------------------------------------------------------------------------------------------|
| name | Balance name. |
| amount | Current balance including STH and Rolling reserve. |
| online-balance-live-amount | Current balance calculated from configuration excluding STH and Rolling reserve. Live = current - STH - RR. |
| total-short-term-hold-amount | Current amount of hold based on Date bumping function. |
| total-rolling-reserve-amount | Current amount calculated from rate plan hold. |
| currency | Currency used for selected balance. |
| merchant Login | Merchant login for the balance. |
| amount-buffer-hold | Calculated amount for OUT operations without final status. |

#### Request Example

```http
POST /paynet/api/v2/get-balance/manager/BalanceTestManager HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="BalanceTestManager",oauth_timestamp="1686924196",oauth_nonce="sT33IbJ4QHs",oauth_signature_method="HMAC-SHA1",oauth_signature="LyKy7M8P%2F%2FZxyLnh7ULW405ODVs%3D"
Content-Length: 156
Content-Type: application/x-www-form-urlencoded
Connection: close

balance-name=saa
&oauth_consumer_key=BalanceTestManager
&oauth_nonce=sT33IbJ4QHs
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1686924196
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 16 May 2023 08:06:05 GMT
Content-Length: 192
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

[
  {
    "name":"saa",
    "amount":219.500,
    "online-balance-live-amount":219.500,
    "total-short-term-hold-amount":0.000,
    "total-rolling-reserve-amount":0.000,
    "currency":"USD",
    "merchantLogin":"balance_test_merchant14",
    "externalMerchantIdentifier":null,
    "amount-buffer-hold":0.000
  }
]
```

#### Fail Response Example

```http
HTTP/1.1 403
Server: server
Date: Fri, 16 Jun 2023 13:23:37 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

...
<body>
    <p>Access is denied</p>
</body>
```

### /api/v2/get-balance/merchant

#### Introduction

Get Balance by Merchant is initiated through HTTPS POST request by using [URLs](#api-v2-get-balance-merchant-request-url) and the [parameters](#api-v2-get-balance-merchant-request-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). Also can be viewed on UI. Please contact support managers to enable this feature.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/get-balance/merchant/MERCHANTLOGIN | https://gate.payneteasy.eu/paynet/api/v2/get-balance/merchant/MERCHANTLOGIN |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| balance-name | Balance name. If this parameter is omitted, the result will give all available balances. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|------------------------------|--------------------------------------------------------------------------------------------------------------|
| name | Balance name. |
| amount | Current balance including STH and Rolling reserve. |
| online-balance-live-amount | Current balance calculated from configuration excluding STH and Rolling reserve. Live = current - STH - RR.. |
| total-short-term-hold-amount | Current amount of hold based on Date bumping function. |
| total-rolling-reserve-amount | Current amount calculated from rate plan hold. |
| currency | Currency used for selected balance. |
| amount-buffer-hold | Calculated amount for OUT operations without final status. |

#### Request Example

```http
POST /paynet/api/v2/get-balance/merchant/balance_test_merchant14 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="balance_test_merchant14",oauth_timestamp="1686924613",oauth_nonce="qoJPcins4Aw",oauth_signature_method="HMAC-SHA1",oauth_signature="M6fTXbI0tFz4Dy7YEL3SBzCN1I0%3D"
Content-Length: 161
Content-Type: application/x-www-form-urlencoded
Connection: close

balance-name=saa
&oauth_consumer_key=balance_test_merchant14
&oauth_nonce=qoJPcins4Aw
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1686924613
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 16 May 2023 08:06:05 GMT
Content-Length: 192
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

[
  {
    "name":"Test1",
    "amount":8854.000,
    "online-balance-live-amount":8854.000,
    "total-short-term-hold-amount":0.000,
    "total-rolling-reserve-amount":0.000,
    "currency":"AUD",
    "amount-buffer-hold":0.000
  }
]
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 16 May 2023 08:06:05 GMT
Content-Length: 192
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

...
<body>
    <p>Access is denied</p>
</body>
```

### /api/v2/make-rebill-preauth

#### Introduction

Preauth recurring transactions are initiated through HTTPS POST request to the [URLs](#make-rebill-request-url) and the [parameters](#make-rebill-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/make-rebill-preauth/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/make-rebill-preauth/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/make-rebill-preauth/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/make-rebill-preauth/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| login | Connecting Party’s login name. | `Necessity`: Required `Type`: String `Length`: 20 |
| client_orderid | Connecting Party’s order identifier of the transaction. | `Necessity`: Required `Type`: String `Length`: 128 |
| cardrefid | Card reference ID obtained at Card Registration Stage [/api/v2/create-card-ref/](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Required `Type`: String `Length`: 20 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| enumerate_amounts | This parameter may comprise multiple amounts, separated with ,. Payneteasy will cycle through the amounts of the list, try to make a payment on that amount, until there are no more amounts from the list, or not get approved. | `Necessity`: Optional `Type`: String `Length`: 128 |
| recurrent_scenario | Type of the rebill transaction. Possible values: REGULAR or IRREGULAR. If this parameter is sent in the request, it will have priority over the same parameter specified on gate level. Only used for specific acquirers. | `Necessity`: Optional `Type`: String `Length`: 50 |
| recurrent_initiator | Initiator of the rebill transaction. Possible values: CARDHOLDER or MERCHANT. If this parameter is sent in the request, it will have priority over the same parameter specified on gate level. Only used for specific acquirers. | `Necessity`: Optional `Type`: String `Length`: 50 |
| cvv2 | Customer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card. May be empty or absent if bank gateway supports processing without CVV2. | `Necessity`: Optional `Type`: Numeric `Length`: 3-4 |
| ipaddress | Customer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| comment | A short comment. | `Necessity`: Optional `Type`: String `Length`: 50 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login 2. Request parameter: client_orderid 3. Request parameter: cardrefid 4. Request parameter: amount in minor units (if sent). 5. request parameter: currency 6. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; mail@example.com etc. This value will be used by fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. Parameter is required for 3DS flow and optional for non-3DS. https://doc.payneteasy.com can be used for testing purposes if it’s unknown whether 3DS is used or not. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Sale Response Parameters | Description |
|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| merchant-order-id | Connecting Party’s order id. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| end-point-id | ID of the used End Point. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/make-rebill-preauth/46750 HTTP/1.1
Host: https://sandbox.payneteasy.eu
User-Agent: curl/7.85.0
Accept: */
Content-Length: 229
Content-Type: application/x-www-form-urlencoded
Connection: close

&login=login
&client_orderid=902B4FF5
&cardrefid=1461665
&amount=5.00
&currency=USD
&cvv2=321
&ipaddress=34.129.65.12
&comment=Information abount Rebill
&order_desc=Rebill order description
&control=a37f4972233b4a5dbfb4dcaae149ce7feed01ef9
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 13:10:44 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 144

&type=async-response
&serial-number=00000000-0000-0000-0000-000002e0d498
&merchant-order-id=902B4FF5
&paynet-order-id=6937030
&end-point-id=46750
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 13:18:50 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 164

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e0d614
&merchant-order-id=902B4FF5
&error-message=End+point+with+id+99999+not+found
&error-code=3
```

### /api/v2/make-rebill-sale

#### Introduction

Recurring transactions are initiated through HTTPS POST request to the [URLs](#api-v2-make-rebill-request-url) and the [parameters](#api-v2-make-rebill-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/make-rebill-sale/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/make-rebill-sale/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/make-rebill-sale/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/make-rebill-sale/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| login | Connecting Party’s login name. | `Necessity`: Required `Type`: String `Length`: 20 |
| client_orderid | Connecting Party’s order identifier of the transaction. | `Necessity`: Required `Type`: String `Length`: 128 |
| cardrefid | Card reference ID obtained at Card Registration Stage [/api/v2/create-card-ref/](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Required `Type`: String `Length`: 20 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| enumerate_amounts | This parameter may comprise multiple amounts, separated with ,. Payneteasy will cycle through the amounts of the list, try to make a payment on that amount, until there are no more amounts from the list, or not get approved. | `Necessity`: Optional `Type`: String `Length`: 128 |
| recurrent_scenario | Type of the rebill transaction. Possible values: REGULAR or IRREGULAR. If this parameter is sent in the request, it will have priority over the same parameter specified on gate level. Only used for specific acquirers. | `Necessity`: Optional `Type`: String `Length`: 50 |
| recurrent_initiator | Initiator of the rebill transaction. Possible values: CARDHOLDER or MERCHANT. If this parameter is sent in the request, it will have priority over the same parameter specified on gate level. Only used for specific acquirers. | `Necessity`: Optional `Type`: String `Length`: 50 |
| cvv2 | Customer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card. May be empty or absent if bank gateway supports processing without CVV2. | `Necessity`: Optional `Type`: Numeric `Length`: 3-4 |
| ipaddress | Customer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| comment | A short comment. | `Necessity`: Optional `Type`: String `Length`: 50 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login 2. Request parameter: client_orderid 3. Request parameter: cardrefid 4. Request parameter: amount in minor units (if sent). 5. request parameter: currency 6. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; mail@example.com etc. This value will be used by fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. Parameter is required for 3DS flow and optional for non-3DS. https://doc.payneteasy.com can be used for testing purposes if it’s unknown whether 3DS is used or not. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Sale Response Parameters | Description |
|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| merchant-order-id | Connecting Party’s order ID. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| end-point-id | ID of the used End Point. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/make-rebill-sale/46750 HTTP/1.1
Host: https://sandbox.payneteasy.eu
User-Agent: curl/7.85.0
Accept: */
Content-Length: 229
Content-Type: application/x-www-form-urlencoded
Connection: close

&login=login
&client_orderid=902B4FF5
&cardrefid=1461665
&amount=5.00
&currency=USD
&cvv2=123
&ipaddress=34.129.65.12
&comment=Information abount Rebill
&order_desc=Rebill order description
&control=a37f4972233b4a5dbfb4dcaae149ce7feed01ef9
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 13:22:04 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 144

type=async-response
&serial-number=00000000-0000-0000-0000-000002e0d6b9
&merchant-order-id=902B4FF5
&paynet-order-id=6937242
&end-point-id=46750
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 02 Feb 2023 13:24:47 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 164

type=validation-error
&serial-number=00000000-0000-0000-0000-000002e0d74c
&merchant-order-id=902B4FF5
&error-message=End+point+with+id+99999+not+found
&error-code=3
```

### /api/v2/pan-eligibility/form

#### Introduction

PAN Eligibility form is initiated through HTTPS POST request by using [URLs](#api-v2-pan-eligibility-form-request-url) and the [parameters](#api-v2-pan-eligibility-form-request-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### PAN Eligibility API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Method | Integration | Production |
|----------------|-------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| Sending-only | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/send-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/send-form/ENDPOINTID |
| Receiving-only | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/receive-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/receive-form/ENDPOINTID |
| Both | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/both-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/both-form/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Send-form Request Example

```http
POST /paynet/api/v2/pan-eligibility/send-form/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="javid_test_merch",oauth_timestamp="1687507473",oauth_nonce="Gs2vcwIXv6H",oauth_signature_method="HMAC-SHA1",oauth_signature="sMQWXIUY0OTgBzt2OavSFhT3Q3s%3D"
Content-Length: 192
Content-Type: application/x-www-form-urlencoded
Connection: close

client-order-id=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=Gs2vcwIXv6H
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687507473
&oauth_version=1.0
&redirect-url=http%3A%2F%2Fsandbox.payneteasy.eu%2Fdoc%2Fdummy.htm
```

#### Send-form Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 21 Jun 2023 11:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 147

type=async-response
&serial-number=00000000-0000-0000-0000-000002ec863e
&merchant-order-id=1234567890
&paynet-order-id=7211136
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Fpan-eligibility%2Finit%2FBB3757784F4A53585143535A554E2F4D6A3264715A616E744C6C31667043414962654534575039376E636F343D
```

#### Send-form Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 12:59:09 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

#### Receive-form Request Example

```http
POST /paynet/api/v2/pan-eligibility/receive-form/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="javid_test_merch",oauth_timestamp="1687511712",oauth_nonce="cRmRev3FdaP",oauth_signature_method="HMAC-SHA1",oauth_signature="6zWG0Sli0dehdFikhoGdoEqhcQA%3D"
Content-Length: 226
Content-Type: application/x-www-form-urlencoded
Connection: close

client-order-id=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=cRmRev3FdaP
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687511712
&oauth_version=1.0
&redirect-url=http%3A%2F%2Fsandbox.payneteasy.eu%2Fdoc%2Fdummy.htm
```

#### Receive-form Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 21 Jun 2023 12:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 147

type=async-response
&serial-number=00000000-0000-0000-0000-000002ec863e
&merchant-order-id=1234567890
&paynet-order-id=7211136
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Fpan-eligibility%2Finit%2FBB3757784F4A53585143535A554E2F4D6A3264715A616E744C6C316670434149626545436159574254497A4D3D
```

#### Receive-form Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 12:59:09 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

#### Both-form Request Example

```http
POST /paynet/api/v2/pan-eligibility/both-form/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="javid_test_merch",oauth_timestamp="1687512444",oauth_nonce="Nu8SL8l70H2",oauth_signature_method="HMAC-SHA1",oauth_signature="wypHgzYjxmKrdshhj1CabwPGnnA%3D"
Content-Length: 226
Content-Type: application/x-www-form-urlencoded
Connection: close

client-order-id=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=Gs2vcwIXv6H
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687507765
&oauth_version=1.0
&redirect-url=http%3A%2F%2Fsandbox.payneteasy.eu%2Fdoc%2Fdummy.htm
```

#### Both-form Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 21 Jun 2023 13:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 147

type=async-response
&serial-number=00000000-0000-0000-0000-000002ec863e
&merchant-order-id=1234567890
&paynet-order-id=7211136
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Fpan-eligibility%2Finit%2FBB3757784F4A53585143535A554E2F4D6A3264715A616E744C6C31667043414962654534575039376E636F343D
```

#### Both-form Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 13:19:09 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

### /api/v2/pan-eligibility

#### Introduction

PAN Eligibility is initiated through HTTPS POST request by using [URLs](#api-v2-pan-eligibility-request-url) and the [parameters](#api-v2-pan-eligibility-request-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### PAN Eligibility API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Method | Integration | Production |
|----------------|--------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| Sending-only | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/send/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/send/ENDPOINTID |
| Receiving-only | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/receive/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/receive/ENDPOINTID |
| Both | https://sandbox.payneteasy.eu/paynet/api/v2/pan-eligibility/both/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/both/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Sending-only

| Parameter | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| sending-card-number | Sender\`s credit card number. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| card-printed-name | Sender\`s card printed name. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: String `Length`: 128 |
| expire-month | Sender credit card’s month of expiration. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 2 |
| expire-year | Sender credit card’s year of expiration. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 4 |
| sending-card-ref-id | Sender\`s card ref ID. (if sending-card-number is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 20 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Receiving-only

| Parameter | Description | Value |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| receiving-card-number | Receiver\`s credit card number. (if receiving-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| receiving-card-ref-id | Receiver\`s card ref ID. (if receiving-card-number is not specified) | `Necessity`: Required `Type`: Numeric `Length`: |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Both

| Parameter | Description | Value |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| sending-card-number | Sender\`s card number. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| card-printed-name | Sender\`s card printed name. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: String `Length`: 128 |
| expire-month | Sender credit card’s month of expiration. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 2 |
| expire-year | Sender credit card’s year of expiration. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 4 |
| sending-card-ref-id | Sender\`s card ref ID. (if sending-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 20 |
| receiving-card-number | Receiver\`s card number. (if receiving-card-ref-id is not specified) | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| receiving-card-ref-id | Receiver\`s card ref ID. (if receiving-card-number is not specified) | `Necessity`: Required `Type`: Numeric `Length`: |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Send Request Example

```http
POST /paynet/api/v2/pan-eligibility/send/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1687507082",oauth_nonce="XQkXQgLxhCE",oauth_signature_method="HMAC-SHA1",oauth_signature="lLTiOEyUY%2FwibmGVA%2F5rY6qIS9I%3D"
Content-Length: 192
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=XQkXQgLxhCE
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687507082
&oauth_version=1.0
&sending-card-ref-id=1461790
```

#### Send Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 21 Jun 2023 11:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 147

type=async-response
&serial-number=00000000-0000-0000-0000-000002ecbcba
&merchant-order-id=1234567890
&paynet-order-id=7216063
&end-point-id=39907
```

#### Send Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 11:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

#### Receive Request Example

```http
POST /paynet/api/v2/pan-eligibility/receive/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1687507082",oauth_nonce="XQkXQgLxhCE",oauth_signature_method="HMAC-SHA1",oauth_signature="lLTiOEyUY%2FwibmGVA%2F5rY6qIS9I%3D"
Content-Length: 192
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=XQkXQgLxhCE
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687507082
&oauth_version=1.0
&receiving-card-number=4444555566661111
```

#### Receive Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 21 Jun 2023 12:19:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 147

type=async-response
&serial-number=00000000-0000-0000-0000-000002ecbcba
&merchant-order-id=1234567890
&paynet-order-id=7216063
&end-point-id=39907
```

#### Receive Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 12:19:29 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

#### Both Request Example

```http
POST /paynet/api/v2/pan-eligibility/both/39907 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1687513856",oauth_nonce="T0z9qml2rDZ",oauth_signature_method="HMAC-SHA1",oauth_signature="rsHewN7TRIxzPQAtd99z5eoSyJY%3D"
Content-Length: 231
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=1234567890
&oauth_consumer_key=test_merch
&oauth_nonce=T0z9qml2rDZ
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687513856
&oauth_version=1.0
&receiving-card-number=4444555566661111
&sending-card-ref-id=1461790
```

#### Both Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 23 Jun 2023 09:51:15 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 146

type=async-response
&serial-number=00000000-0000-0000-0000-000002ecbcc2
&merchant-order-id=1234567890
&paynet-order-id=7216068
&end-point-id=39907
```

#### Both Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 22 Aug 2022 13:19:29 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 154

...
<body>
    <p>Access is denied</p>
</body>
```

### /api/v2/payout-form

#### Introduction

Payout-form is initiated through HTTPS POST request by using [URLs](#api-v2-payout-form-url) and the [parameters](#api-v2-payout-form-parameters) specified below. Use [OAuth HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|----------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/payout-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/payout-form/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/payout-form/group/ENDPOINTIDGROUPID | https://gate.payneteasy.eu/paynet/api/v2/payout-form/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Ask support manager if conditional fields are required for integration.
 

| Parameter Name | Description | Value |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party’s order identifier. | `Necessity`: Required `Type`: String `Lenght`: 128 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Lenght`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 65K |
| ipaddress | Receiver’s IP address (IPv4 or IPv6). | `Necessity`: Conditional `Type`: String `Length`: 7-45 |
| purpose | Payout purpose. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_url | URL, where the Receiver is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return Receiver anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Required if both redirect_success_url and redirect_fail_url are missing `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Receiver is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Receiver anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Required if redirect_url parameter is missing `Type`: String `Lenght`: 1024 |
| redirect_fail_url | URL, where the Receiver is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you use non-3DS schema for transactions processing and you have no need to return Receiver anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Required if redirect_url parameter is missing `Type`: String `Length`: 1024 |
| account_number | Account number. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| account_name | Bank account. | `Necessity`: Conditional `Type`: String `Length`: 512 |
| ewallet_wallet | E-wallet ID. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| crypto_wallet_address | Address of crypto wallet. | `Necessity`: Conditional `Type`: String `Length`: 64 |
| bank_name | Bank Name. | `Necessity`: Conditional `Type`: String `Length`: 512 |
| bank_branch | Bank Branch Name. | `Necessity`: Conditional `Type`: String `Length`: 512 |
| bank_code | Bank code. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| bank_address1 | Bank address. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_zip_code | Bank postal ZIP code. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| bank_province | Bank province. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| bank_area | Bank area. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| bank_city | Bank city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| routing_number | Routing number used to identify specific bank branches in China. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| legal_person_name | Name on the legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| legal_person_document_number | Number of legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_first_name | Receiver first name, also can be sent as first_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_last_name | Receiver last name, also can be sent as last_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_birthday | Receiver birthday, also can be sent as birthday. | `Necessity`: Conditional `Type`: Numeric `Length`: 30 |
| receiver_country_code | Receiver country code, also can be sent as country. | `Necessity`: Conditional `Type`: String `Length`: 3 |
| receiver_state | Receiver state, should be provided for countries that have states (USA, Canada, Australia), also can be sent as state. | `Necessity`: Conditional `Type`: String `Length`: 4 |
| receiver_city | Receiver city, also can be sent as city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_zip_code | Receiver zip code, also can be sent as zip_code. | `Necessity`: Conditional `Type`: Numeric `Length`: 32 |
| receiver_address1 | Receiver address, also can be sent as address1. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| receiver_phone | Receiver phone, also can be sent as phone. | `Necessity`: Conditional `Type`: Numeric `Length`: 128 |
| receiver_email | Receiver E-mail, also can be sent as email. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_id | Receiver identity document identifier, also can be sent as identity_document_id. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_number | Receiver identity document number, also can be sent as identity_document_number. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party’s Callback. | `Necessity`: Optional `Type`: String `Length`: 65k |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 2M |
| preferred_language | Preferred language. | `Necessity`: Optional `Type`: String `Length`: 2 |

#### Response Parameters

> **Note:** Response has a Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter Name | Description |
|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| redirect_url | The URL to the page where the Connecting Party should redirect the client’s browser. Connecting Party should send HTTP 302 redirect. |

#### Request Example

```http
POST /paynet/api/v2/payout-form/39529 HTTP/1.1
Host: sandbox.doc2.com
User-Agent: curl/8.12.1
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="merchantlogin",oauth_timestamp="1753337681",oauth_nonce="T5v7kcMBsgi",oauth_signature_method="HMAC-SHA1",oauth_signature="wTTQQiN%2F2bGjfCTcSAQ3ZhAHMLw%3D"
Content-Length: 249
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

account_number=1234567890
&order_desc=Test_Order_Description
&amount=100
&bank_branch=test_branch
&bank_name=test_bank
&client_orderid=12345
&currency=USD
&oauth_consumer_key=merchantlogin
&oauth_nonce=T5v7kcMBsgi
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1753337681
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 24 Jul 2025 06:45:56 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 142

type=async-response
&serial-number=00000000-0000-0000-0000-000002f3b45d
&merchant-order-id=12345
&paynet-order-id=7366391
&end-point-id=132490
```

#### Fail Response Example

```http
HTTP/1.1 403
Server: server
Date: Thu, 24 Jul 2025 06:26:23 GMT
Content-Type: application/x-www-form-urlencoded;charset=UTF-8
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Length: 102

type=error
&serial-number=00000000-0000-0000-0000-000002f3b456
&error-message=Forbidden
&error-code=-1
```

#### Test Scenario

Different Payout transaction statuses can be received on sandbox, depending on the account_number value passed in Payout request.

Testing account_number values:

> * account_number = 1234567890 to get APPROVED
> * account_number = 0987654321 to get DECLINED
> * account_number = 1987654321 to get PROCESSOR_INTERNAL_ERROR

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/payout-form/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/preauth-form

#### Introduction

Preauth-form is initiated through HTTPS POST request by using [URLs](#api-v2-preauth-form-url) and the [parameters](#api-v2-preauth-form-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------------|-----------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/preauth-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/preauth-form/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/preauth-form/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/preauth-form/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Acquirer can redefine the necessity of some fields so they become required instead of optional.
 
Leading and trailing whitespace in input parameters will be omitted.
 

| Parameter Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-v2-preauth-form-url)). 2. Request parameter: client_orderid. 4. Request parameter: amount in minor units (if sent). 4. Request parameter: email. 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| first_name | Payer’s first name. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| ssn | Last four digits of the Payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Payer’s two-letter language code for multi-language payment-forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in MERCHANT_FORM_DATA API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| minimum_transaction_amount | This parameter can be used to limit the minimum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| maximum_transaction_amount | This parameter can be used to limit the maximum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| customer_level | Customer level in CMS system | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode) | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Merchant Customer ID in CMS system. Required if transaction goes via CMS (CRM mode) | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| preferred_language | Payer’s two-letter language code for multi-language payment forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| card_recurring_payment_id | Payer’s tokenized cardholder’s data ID, referred as Recurring Payment ID (RPI). Recurring Payment ID can be created with [v4 tokenization request](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long |
| cardrefid | Card reference ID used in subsequent recurring payments. Card reference ID can be created with [v4 tokenization request](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) or [v2 tokenization request](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| redirect-url | The URL to the page where the Connecting Party should redirect the client’s browser. Connecting Party should send HTTP 302 redirect, see [General Payment-form Process Flow](https://doc.payneteasy.com/integration/api_use_cases/sale_form.html.md). |

#### Request Example

```http
POST /paynet/api/v2/preauth-form/39539 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&amount=69
&email=john.smith@gmail.com
&currency=USD
&ipaddress=65.153.12.232
&site_url=https://doc.payneteasy.com
&credit_card_number=4538977399606732
&card_printed_name=CARD HOLDER
&expire_month=12
&expire_year=2099
&cvv2=123
&purpose=user_account1
&redirect_url=http://sandbox.payneteasy.eu/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&merchant_form_data=testparam%3Dtest1%26mynewparam%3Dtest2
&control=b7ba0b0ce36fda192c3772e045520c7a9cb5e442
&preferred_language=en
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Thu, 13 Oct 2022 09:54:53 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 280

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddb0d3
&merchant-order-id=Test
&paynet-order-id=6863103
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A68633370432F78675258396E6F78367975715973596936522B594B4F646168553D
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Thu, 13 Oct 2022 09:58:28 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 170

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb0d4
&error-message=Project+with+currency+RUB+does+not+apply+request+with+currency+USD
&error-code=16
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/preauth-form/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/preauth

#### Introduction

Preauth is initiated through HTTPS POST request by using [URLs](#api-v2-preauth-request-url) and the [parameters](#api-v2-preauth-request-parameters-url) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------|------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/preauth/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/preauth/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/preauth/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/preauth/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Parameter Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 125 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-v2-preauth-request-url)). 2. Request parameter: client_orderid. 3. Request parameter: amount in minor units (if sent). 4. Request parameter: email. 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| cvv2 | Payer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number printed on the back of the card in the signature area. | `Necessity`: Required `Type`: Numeric `Length`: 3-4 |
| credit_card_number | Payer’s bank card number (also known as PAN - Primary Account Number). | `Necessity`: Required `Type`: Numeric `Length`: 20 |
| card_recurring_payment_id | Payer’s tokenized cardholder’s data ID. Send either card_recurring_payment_id or combination of credit_card_number, card_printed_name, expire_month and expire_year, not all. To create card_recurring_payment_id see [/api/v2/create-card-ref](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Required `Type`: Long `Length`: 20 |
| card_printed_name | Cardholder name, printed on the bank card. | `Necessity`: Required `Type`: String `Length`: 64k |
| expire_month | Bank card expiration month. | `Necessity`: Required `Type`: Numeric `Length`: 2 |
| expire_year | Bank card expiration year. | `Necessity`: Required `Type`: Numeric `Length`: 4 |
| first_name | Payer’s first name. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| ssn | Last four digits of the payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Partys who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| merchant_data | Custom Connecting Party details, which can be attached to the transaction and passed back in the [status response](https://doc.payneteasy.com/integration/api_v2_status.html.md), [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md) or server_callback_url. Additional information of transaction which may be useful in Connecting Party’s external system, e.g. VIP customer, TV promo campaign lead. Information returns in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64k |
| minimum_transaction_amount | This parameter can be used to limit the minimum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| maximum_transaction_amount | This parameter can be used to limit the maximum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| customer_level | Customer level in CMS system | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode) | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Merchant Customer ID in CMS system. Required if transaction goes via CMS (CRM mode) | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| recurring-payment-id | Recurring Payment ID can be sent instead of cardholder data. CVV for native is not needed. Customer Data can be updated via [/api/v4/update-recurring-payment/](https://doc.payneteasy.com/integration/api_v4_update-recurring-payment.html.md). Recurring Payment ID creation is initiated through HTTPS POST request by using [URLs](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) and the [parameters](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. | `Necessity`: Conditional `Type`: Long |

#### Additional Fields for Preauth Transactions

##### For Connecting Party

> **Note:** Browser data for 3DS 2. X is gathered by Payneteasy system on 3DS authentication stage. For some processing channels, however, the browser data and/or Connecting Party URL for 3DS challenge results must be provided in initial transaction request. Please contact Support manager to clarify if these parameters should be included in request parameters.

The Connecting Party’s site needs to accurately populate the browser information for each transaction. This data can be obtained by Connecting Party’s servers. Ensure that the data is not altered or hard-coded, and that it is unique to each transaction.

| Parameter Name | Description | Value |
|----------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| ipaddress | IP address of the browser as returned by the HTTP headers to the 3DS Requestor. | `Necessity`: Required `Type`: String `Length`: 45 |
| customer_browser_accept_header | Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder’s browser. | `Necessity`: Required `Type`: String `Length`: 2048 |
| customer_browser_javascript_enabled | Boolean that represents the ability of the cardholder browser to execute Java Script. | `Necessity`: Required `Type`: Boolean `Length`: - |
| customer_browser_accept_language | Value representing the browser language as defined in IETF BCP47. | `Necessity`: Required `Type`: String `Length`: 8 |
| customer_browser_user_agent | Exact content of the HTTP user-agent header. | `Necessity`: Required `Type`: String `Length`: 2048 |
| tds_areq_notification_url, alias tds_cres_notification_url | Fully qualified URL of Connecting Party system that will receive the CRes message or Error Message. This CRes message must be sent to Payneteasy. See details here [Upload CRes Result](https://doc.payneteasy.com/integration/upload-cres-result.html.md). | `Necessity`: Optional `Type`: String `Length`: 256 |
| customer_browser_info | If true, then the fields below must be present. | `Necessity`: Optional `Type`: Boolean `Length`: - |
| customer_browser_color_depth | Value representing the bit depth of the colour palette for displaying images, in bits per pixel. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: String `Length`: 2 |
| customer_browser_java_enabled | Boolean that represents the ability of the cardholder browser to execute Java. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Boolean `Length`: - |
| customer_browser_screen_height | Total height of the Cardholder’s screen in pixels. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Numeric `Length`: 6 |
| customer_browser_screen_width | Total width of the cardholder’s screen in pixels. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Numeric `Length`: 6 |
| customer_browser_time_zone | Time-zone offset in minutes between UTC and the Cardholder browser local time. Note that the offset is positive if the local time zone is behind UTC and negative if it is ahead. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: String `Length`: 5 |

##### For Payment Institutions

The PSP or Acquirer can fill the 3DS results for each transaction, if 3DS authentication is performed on their side.

| Parameter Name | Description | Value |
|------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| tds_authentication_result_type | Type of result. Possible values are: - SIMPLE | `Type`: String `Length`: 6 |
| tds_authentication_result_authentication_type | Authentication Type. Indicates the type of authentication method the Issuer will use to challenge the Cardholder, whether in the ARes message or what was used by the ACS when in the RReq message. Possible values are: - 01 = Static - 02 = Dynamic - 03 = OOB - 04 = Decoupled - 05-79 = Reserved for EMVCo future use (values invalid until defined by EMVCo) - 80-99 = Reserved for DS use | `Type`: String `Length`: 2 |
| tds_authentication_result_authentication_value | Authentication Value. Payment System-specific value provided by the ACS or the DS using an algorithm defined by Payment System. Authentication Value may be used to provide proof of authentication. A 20-byte value that has been Base64 encoded, giving a 28-byte result | `Type`: String `Length`: 19-28 |
| tds_authentication_result_transaction_id | xid for 1.0.2 or ds TransID for 2.1.0/2.2.0 | `Type`: String `Length`: 19-36 |
| tds_authentication_result_transaction_status | Transaction Status. Indicates whether a transaction qualifies as an authenticated transaction or account verification. Possible values are: - Y = Authentication Verification Successful - N = Not Authenticated/Account Not Verified, Transaction denied - U = Authentication/Account Verification Could Not Be Performed, Technical or other problem, as indicated in ARes or RReq - A = Attempts Processing Performed, Not Authenticated/Verified, but a proof of attempted authentication/verification is provided - C = Challenge Required, Additional authentication is required using the CReq/CRes - D = Challenge Required, Decoupled Authentication confirmed - R = Authentication/ Account Verification Rejected, Issuer is rejecting | `Type`: String `Length`: 1 |
| tds_authentication_result_message_version | Message Version Number. Protocol version identifier This shall be the Protocol Version Number of the specification utilised by the system creating this message. The Message Version Number is set by the 3DS Server which originates the protocol with the AReq message. The Message Version Number does not change during a 3DS transaction. Possible values are: - 1.0.2 - 2.1.0 - 2.2.0 | `Type`: String `Length`: 5 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| end-point-id | Endpoint id used for the transaction. |

#### Request with Cardholder Data Example

```http
POST /paynet/api/v2/preauth/39549 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

credit_card_number=4538977399606732
&card_printed_name=CARD HOLDER
&expire_month=12
&expire_year=2099
&cvv2=123
&client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=%2B12063582043
&cell_phone=%2B19023384543
&email=john.smith@gmail.com
&currency=USD
&amount=10.42
&ipaddress=65.153.12.232
&site_url=https://doc.payneteasy.com
&purpose=user_account1
&redirect_url=https://doc.payneteasy.com/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&control=768eb8162fc361a3e14150ec46e9a6dd8fbfa483
```

#### Request with Card Recurring Payment ID Example

```http
POST /paynet/api/v2/preauth/39549 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

card_recurring_payment_id=1491927
&cvv2=123
&client_orderid=34T43R77N
&order_desc=Test Order Description
&amount=777
&currency=USD
&ipaddress=65.153.12.232
&redirect_url=https://doc.payneteasy.com/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&control=218d377897ce25c2ac69d99de42bc6902eb5bcd8
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 05 Sep 2022 10:43:57 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 139

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddb018
&merchant-order-id=123
&paynet-order-id=6863073
&end-point-id=39914
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 05 Sep 2022 10:51:14 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 208

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb019
&merchant-order-id=123
&error-message=Validate+card+number+failed.+Card+Number+length+must+be+between+16+and+19+digits..
&error-code=8
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/preauth/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/return

#### Introduction

Return transactions may only be initiated when the transaction have final successful status. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). For Preauth it makes Cancel transaction, for Capture and Sale – Reversal. Return transactions are initiated through HTTPS POST request by using [URLs](#api-v2-return-request-url) and the [parameters](#api-v2-return-request-parameters-url) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------|-----------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/return/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/return/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/return/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/return/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

> **Warning:** The following characters must be escaped in the parameter values: & + “.

| Parameter Name | Description | Value |
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| login | Connecting Party login name. | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| orderid | Unique order identifier assigned by Payneteasy system. | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| client_orderid | Unique Connecting Party identifier. | `Necessity`: Mandatory `Type`: String `Length`: 128 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login. 2. Request parameter: client_orderid. 3. Request parameter: orderid. 4. Request parameter: amount (in minor units, if sent). 5. Request parameter: currency (if sent). 6. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Conditional `Type`: String `Length`: 128 |
| amount | The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. If this parameter is omitted, initial transaction is reversed as a whole. Amount only makes sense for reversals, not cancels. Amount cannot exceed initial transaction amount. Please note that Currency MUST be specified if amount is specified! | `Necessity`: Mandatory `Type`: Numeric `Length`: 10 |
| currency | Currency in which amount is specified. Provided in three-letter currency code format. Example: USD for US Dollar. Reference: [Currency Codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md). | `Necessity`: Mandatory `Type`: String `Length`: 50 |
| comment | A brief description of reason. | `Necessity`: Mandatory `Type`: String `Length`: 50 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter Name | Description |
|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| end-point-id | Entry point used for processing this transaction. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/return/39914 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 162
Content-Type: application/x-www-form-urlencoded
Connection: close

login=TestMerchant
&client_orderid=Test
&orderid=6862958
&amount=5.00
&currency=RUB
&comment=Service not provided
&control=2dfdb99c4eff5b31c978ecb8bc4b4d094e24c1d4
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 08 Aug 2022 07:50:08 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 141

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddad4a
&merchant-order-id=Test
&paynet-order-id=6862958
&end-point-id=39914
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 08 Aug 2022 10:45:32 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 153

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddad5c
&error-message=Reversal+currency+does+not+match+project+currency
&error-code=16
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/return/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/sale-echeck

#### Introduction

Sale-e Check is initiated through HTTPS POST request by using [URLs](#api-v2-echeck-request-url) and the [parameters](#api-v2-echeck-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------|-----------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/sale-echeck/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/sale-echeck/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Leading and trailing whitespace in input parameters will be omitted.
 

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| first_name | Payer’s first name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| ssn | Last four digits of the Payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| routing_number | This element should contain the Payer’s 9 digit bank routing number. | `Necessity`: Required `Type`: String `Length`: 9 |
| account_number | This element should contain the Payer’s bank account number. | `Necessity`: Required `Type`: String `Length`: 20 |
| check_number | This element should contain the Payer’s check number. | `Necessity`: Optional `Type`: String `Length`: 22 |
| check_date | This element should contain the Payer’s check date. Format is MM/DD/YYYY. | `Necessity`: Optional `Type`: String `Length`: 12 |
| bank_name | This element should contain the Payer’s bank name. | `Necessity`: Optional `Type`: String `Length`: 12 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID (See: [Request URL](#api-v2-echeck-request-url)) 2. Request parameter: client_orderid 3. Request parameter: amount (in minor units) 4. Request parameter: email 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/sale-echeck/39790 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&amount=10.55
&email=john.smith@gmail.com
&currency=USD
&ipaddress=65.153.12.232
&routing_number=113024588
&account_number=1234567890
&check_number=77778888
&check_date=02/22/2025
&bank_name=testbank
&server_callback_url=https%3A%2F%2Fhttpstat.us%2F200
&control=5ce2641b344bf35930ba9536055d24f038a1065b
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 26 Apr 2023 13:51:16 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 144

type=async-response
&serial-number=00000000-0000-0000-0000-000002e3450d
&merchant-order-id=902B4FF5
&paynet-order-id=6994012
&end-point-id=39790
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 26 Apr 2023 13:51:16 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 144

type=validation-error
&serial-number=00000000-0000-0000-0000-000002b36f64
&merchant-order-id=inv4097763
&error-message=End+point+with+id+39790+not+found
&error-code=3
```

### /api/v2/sale-form

#### Introduction

Sale-form is initiated through HTTPS POST request by using [URLs](#api-v2-sale-form-url) and the [parameters](#api-v2-sale-form-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------|--------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/sale-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/sale-form/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/sale-form/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/sale-form/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Acquirer can redefine the necessity of some fields so they become required instead of optional.
 
Leading and trailing whitespace in input parameters will be omitted.
 

> **Warning:** The following characters must be escaped in the parameter values: & + “.

| Parameter Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| first_name | Payer’s first name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| ssn | Last four digits of the payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party’s who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 20 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-v2-sale-form-url)) 2. Request parameter: client_orderid 3. Request parameter: amount in minor units (if sent). 4. Request parameter: email 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Payer’s two-letter language code for multi-language payment-forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_data | Custom Connecting Party details, which can be attached to the transaction and passed back in the [status response](https://doc.payneteasy.com/integration/api_v2_status.html.md), [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md) or server_callback_url. Additional information of transaction which may be useful in Connecting Party’s external system, e.g. VIP customer, TV promo campaign lead. Information returns in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64k |
| merchant_form_data | Parameters sent in MERCHANT_FORM_DATA API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| minimum_transaction_amount | This parameter can be used to limit the minimum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| maximum_transaction_amount | This parameter can be used to limit the maximum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| customer_level | Customer level in CMS system | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode) | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Merchant Customer ID in CMS system. Required if transaction goes via CMS (CRM mode) | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| card_recurring_payment_id | Payer’s tokenized cardholder’s data ID, referred as Recurring Payment ID (RPI). Recurring Payment ID can be created with [v4 tokenization request](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long |
| cardrefid | Card reference ID used in subsequent recurring payments. Card reference ID can be created with [v4 tokenization request](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) or [v2 tokenization request](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter name | Description |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-form-response, validation-error, error etc.. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is declined or error this parameter contains the reason for decline or error details. |
| error-code | The error code in case of declined or error status. |
| redirect-url | The URL to the page where the Connecting Party should redirect the client’s browser. Connecting Party should send HTTP 302 redirect, see [General Payment-form Process Flow](https://doc.payneteasy.com/integration/api_use_cases/sale_form.html.md). |

#### Request Example

```http
POST /paynet/api/v2/sale-form/39519 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=inv1409911
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&amount=156
&email=john.smith@gmail.com
&currency=USD
&ipaddress=65.153.12.232
&site_url=https://doc.payneteasy.com
&purpose=user_account1
&redirect_url=http://connectingparty.com/result
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&merchant_form_data=testparam%3Dtest1%26mynewparam%3Dtest2
&control=185aea68b751221b78fa9138e9d44a6aa4c2c446
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Tue, 11 Oct 2022 14:25:25 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 280

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddb0b9
&merchant-order-id=Test
&paynet-order-id=6863099
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A68633370432F786752582F6154674965594A696F4D41306C50596E334F5453553D
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Tue, 11 Oct 2022 14:16:06 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 170

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb0b7
&error-message=Project+with+currency+RUB+does+not+apply+request+with+currency+USD
&error-code=16
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/sale-form/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/sale

#### Introduction

Sale is initiated through HTTPS POST request by using [URLs](#api-v2-sale-request-url) and the [parameters](#api-v2-sale-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------|---------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/sale/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/sale/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/sale/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/sale/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

Acquirer can redefine the necessity of some fields so they become required instead of optional.
 
Leading and trailing whitespace in input parameters will be omitted.
 

> **Warning:** The following characters must be escaped in the parameter values: & + “.

| Parameter Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client_orderid | Unique order identifier assigned by Connecting Party. | `Necessity`: Required `Type`: String `Length`: 128 |
| order_desc | Brief order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| address1 | Payer’s address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Required `Type`: String `Length`: 256 |
| city | Payer’s city. | `Necessity`: Required `Type`: String `Length`: 50 |
| zip_code | Payer’s ZIP code. | `Necessity`: Required `Type`: String `Length`: 10 |
| country | Payer’s country. Please see [Country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. | `Necessity`: Required `Type`: String `Length`: 2 |
| phone | Payer’s full international phone number, including country code. | `Necessity`: Required `Type`: String `Length`: 15 |
| email | Payer’s e-mail address. | `Necessity`: Required `Type`: String `Length`: 50 |
| ipaddress | Payer’s IP address, included for fraud screening purposes. | `Necessity`: Required `Type`: String `Length`: 45 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. <ENDPOINTID | ENDPOINTGROUPID (See: [Request URL](#api-v2-sale-request-url)) 2. Request parameter: client_orderid 3. Request parameter: amount (in minor units) 4. Request parameter: email 5. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Required `Type`: String `Length`: 40 |
| cvv2 | Payer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card. | `Necessity`: Required `Type`: Numeric `Length`: 3-4 |
| credit_card_number | Payer’s credit card number. Send either combination of credit_card_number, card_printed_name, expire_month and expire_year or card_recurring_payment_id, not all. | `Necessity`: Conditional `Type`: Numeric `Length`: 20 |
| card_recurring_payment_id | Payer’s tokenized cardholder’s data ID. Send either card_recurring_payment_id or combination of credit_card_number, card_printed_name, expire_month and expire_year, not all. To create card_recurring_payment_id see [/api/v4/create-card-ref](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long `Length`: 20 |
| card_printed_name | Cardholder name, printed on the bank card. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire_month | Bank card expiration month. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| expire_year | Bank card expiration year. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| first_name | Payer’s first name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| last_name | Payer’s last name. Parameter necessity depends on the Acquiring channel and necessity of it must be clarified with Tech Support. | `Necessity`: Required `Type`: String `Length`: 50 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Conditional `Type`: String `Length`: 2-3 |
| redirect_url | URL, where the Payer is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if you have no need to return payer anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL, where the Payer is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Payer is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass http://https://doc.payneteasy.com if there is no need to redirect Payer anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| ssn | Last four digits of the payer’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 32 |
| birthday | Payer’s date of birth, in the format YYYYMMDD. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| cell_phone | Payer’s full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Length`: 15 |
| site_url | The URL of the E-commerce entity, where the payment is originated from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party’s who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| merchant_data | Custom Connecting Party details, which can be attached to the transaction and passed back in the [status response](https://doc.payneteasy.com/integration/api_v2_status.html.md), [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md) or server_callback_url. Additional information of transaction which may be useful in Connecting Party’s external system, e.g. VIP customer, TV promo campaign lead. Information returns in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64k |
| dapi_imei | Unique device identifier. | `Necessity`: Optional `Type`: String `Length`: 32 |
| minimum_transaction_amount | This parameter can be used to limit the minimum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| maximum_transaction_amount | This parameter can be used to limit the maximum transaction amount, if transaction amount is submitted by Payer on the form. Contact support manager to enable this feature. Value format is the same as in the amount parameter. | `Necessity`: Optional `Type`: Numeric `Length`: 10 |
| customer_level | Customer level in CMS system. | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode). | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Connecting Party Customer ID in CMS system. Required if transaction goes via CMS (CRM mode). | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| recurring-payment-id | Recurring Payment ID can be sent instead of cardholder data. CVV for native is not needed. Customer Data can be updated via [/api/v4/update-recurring-payment/](https://doc.payneteasy.com/integration/api_v4_update-recurring-payment.html.md). Recurring Payment ID creation is initiated through HTTPS POST request by using [URLs](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) and the [parameters](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. | `Necessity`: Conditional `Type`: Long |

#### Additional Parameters

##### For Connecting Party

> **Note:** Browser data for 3DS 2. X is gathered by Connecting Party system on 3DS authentication stage. For some processing channels, however, the browser data and/or Connecting Party URL for 3DS challenge results must be provided in initial transaction request. Please contact Support manager to clarify if these parameters should be included in request parameters.

The Connecting Party’s site needs to accurately populate the browser information for each transaction. This data can be obtained by Connecting Party’s servers. Ensure that the data is not altered or hard-coded, and that it is unique to each transaction.

| Parameter Name | Description | Value |
|----------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| customer_browser_accept_header | Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder’s browser. | `Necessity`: Required `Type`: String `Length`: 2048 |
| customer_browser_javascript_enabled | Boolean that represents the ability of the cardholder browser to execute Java Script. | `Necessity`: Required `Type`: Boolean `Length`: - |
| customer_browser_accept_language | Value representing the browser language as defined in IETF BCP47. | `Necessity`: Required `Type`: String `Length`: 8 |
| customer_browser_user_agent | Exact content of the HTTP user-agent header. | `Necessity`: Required `Type`: String `Length`: 2048 |
| customer_browser_info | If true, then the fields below must be present. | `Necessity`: Optional `Type`: Boolean `Length`: - |
| customer_browser_color_depth | Value representing the bit depth of the colour palette for displaying images, in bits per pixel. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: String `Length`: 2 |
| customer_browser_java_enabled | Boolean that represents the ability of the cardholder browser to execute Java. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Boolean `Length`: - |
| customer_browser_screen_height | Total height of the Cardholder’s screen in pixels. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Numeric `Length`: 6 |
| customer_browser_screen_width | Total width of the cardholder’s screen in pixels. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: Numeric `Length`: 6 |
| customer_browser_time_zone | Time-zone offset in minutes between UTC and the Cardholder browser local time. Note that the offset is positive if the local time zone is behind UTC and negative if it is ahead. Becomes required when browser_java Script_enabled = true. | `Necessity`: Optional `Type`: String `Length`: 5 |
| tds_areq_notification_url, alias tds_cres_notification_url | Fully qualified URL of Connecting Party system that will receive the CRes message or Error Message. This CRes message must be sent to Connecting Party. See details here [Upload CRes Result](https://doc.payneteasy.com/integration/upload-cres-result.html.md). | `Necessity`: Optional `Type`: String `Length`: 256 |

##### For Payment Institutions

The PSP or Acquirer can fill the 3DS results for each transaction, if 3DS authentication is performed on their side.

| Parameter Name | Description | Value |
|------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| tds_authentication_result_type | Type of result. Possible values are: - SIMPLE | `Type`: String `Length`: 6 |
| tds_authentication_result_authentication_type | Authentication Type. Indicates the type of authentication method the Issuer will use to challenge the Cardholder, whether in the ARes message or what was used by the ACS when in the RReq message. Possible values are: - 01 = Static - 02 = Dynamic - 03 = OOB - 04 = Decoupled - 05-79 = Reserved for EMVCo future use (values invalid until defined by EMVCo) - 80-99 = Reserved for DS use | `Type`: String `Length`: 2 |
| tds_authentication_result_authentication_value | Authentication Value. Payment System-specific value provided by the ACS or the DS using an algorithm defined by Payment System. Authentication Value may be used to provide proof of authentication. A 20-byte value that has been Base64 encoded, giving a 28-byte result | `Type`: String `Length`: 19-28 |
| tds_authentication_result_transaction_id | xid for 1.0.2 or ds TransID for 2.1.0/2.2.0 | `Type`: String `Length`: 19-36 |
| tds_authentication_result_transaction_status | Transaction Status. Indicates whether a transaction qualifies as an authenticated transaction or account verification. Possible values are: - Y = Authentication Verification Successful - N = Not Authenticated/Account Not Verified, Transaction denied - U = Authentication/Account Verification Could Not Be Performed, Technical or other problem, as indicated in ARes or RReq - A = Attempts Processing Performed, Not Authenticated/Verified, but a proof of attempted authentication/verification is provided - C = Challenge Required, Additional authentication is required using the CReq/CRes - D = Challenge Required, Decoupled Authentication confirmed - R = Authentication/ Account Verification Rejected, Issuer is rejecting | `Type`: String `Length`: 1 |
| tds_authentication_result_message_version | Message Version Number. Protocol version identifier This shall be the Protocol Version Number of the specification utilised by the system creating this message. The Message Version Number is set by the 3DS Server which originates the protocol with the AReq message. The Message Version Number does not change during a 3DS transaction. Possible values are: - 1.0.2 - 2.1.0 - 2.2.0 | `Type`: String `Length`: 5 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter Name | Description |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error etc.. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is declined or error this parameter contains the reason for decline or error details. |
| error-code | The error code in case of declined or error status. |
| end-point-id | Endpoint id used for the transaction. |

#### Request with Cardholder Data Example

```http
POST /paynet/api/v2/sale/39529 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

credit_card_number=4538977399606732
&card_printed_name=John
&expire_month=01
&expire_year=2042
&cvv2=123
&client_orderid=34T43R77N
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100%20Main%20st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&amount=156
&email=john.smith@gmail.com
&currency=RUB
&ipaddress=65.153.12.232
&site_url=https://doc.payneteasy.com
&purpose=user_account1
&redirect_url=http%3A%2F%2Fhttps://doc.payneteasy.com%2Fdoc%2Fdummy.htm
&server_callback_url=https%3A%2F%2Fhttpstat.us%2F200
&merchant_data=VIP customer
&dapi_imei=123
&control=c821e33bd22773c05c23725d0b1d2dbd9f191399
```

#### Request with Card Recurring Payment ID Example

```http
POST /paynet/api/v2/sale/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 317
Content-Type: application/x-www-form-urlencoded
Connection: close

card_recurring_payment_id=1491954
&cvv2=123
&client_orderid=34T43R77N
&order_desc=Test Order Description
&amount=777
&currency=USD
&ipaddress=65.153.12.232
&redirect_url=http://doc2.doc2.com/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&control=80761544c64373d1624240add048d36d42fe528a
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=async-response
&serial-number=00000000-0000-0000-0000-000002d9b22a
&merchant-order-id=inv4097763
&paynet-order-id=6768788
&end-point-id=22903
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 13:14:40 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=validation-error
&serial-number=00000000-0000-0000-0000-000002b36f64
&merchant-order-id=inv4097763
&error-message=End+point+with+id+22903+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/sale/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/status

#### Introduction

To make an order status request one have to send an HTTPS POST request to the [URLs](#status-request-url) and the [parameters](#status-request-parameters) specified below. Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------|-----------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/status/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/status/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/status/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/status/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

| Parameter Name | Description | Necessity |
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| login | Merchant login name. | Mandatory |
| client_orderid | Unique order identifier assigned by merchant. | Mandatory |
| orderid | Order id assigned to the order by Payneteasy. | Conditional |
| by-request-sn | Serial number assigned to the specific request by Payneteasy. If this field exist in status request, status response return for this specific request. Include this parameter to get the status request with the particular transaction stage (can be used in specific cases). To get the latest transaction status, don’t include this parameter in status request. | Optional |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login. 2. Request parameter: client_orderid. 3. Request parameter: orderid. 4. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | Mandatory |
 
In most common cases, the best option is to include both client_orderid and orderid parameters to status request. Order status can be requested with only client_orderid if it’s unique to merchant and orderid is not received. If orderid is not received in response, but this response contains an error, see the received error message to get the information why transaction was not created in the system.
 

#### Response Parameters

The same API command for status request is used in multiple Use-Cases, therefore some of the mentioned response parameters might not be present for specific case. Below is the full list of possible parameters.
 

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

\* - these parameters are not defined by default. Please contact tech support to include these fields in callback.
 

| Status Response Parameter | Description |
|-------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be status-response. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| amount | Actual transaction amount. This value can be changed during the transaction flow. |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar EUR for European Euro. |
| paynet-order-id | Order id assigned to the order by gate.payneteasy.eu. |
| merchant-order-id | Connecting Party order id. |
| phone | Payer’s full international phone number, including country code. |
| html | HTML code of 3DS authorization form, encoded in application/x-www-form-urlencoded MIME format. Merchant must decode this parameter before showing the form to the Payer. gate.payneteasy.eu System returns the following response parameters when it gets 3DS authorization form from the Issuer Bank. It contains auth form HTML code which must be passed through without any changes to the client’s browser. This parameter exists and has value only when the redirection HTML is already available. For non-3DS this never happens. For 3DS HTML has value after some short time after the processing has been started. |
| redirect-to | For 3DS authorization the merchant can redirect the Payer to URL provided in this parameter instead of rendering the page provided in html parameter. The redirect-to parameter is returned only if the html parameter is returned. Merchant should use GET HTTP method to redirect. This parameter must be used to work with 3DS 2.0. |
| serial-number | Unique number assigned by gate.payneteasy.eu server to particular request from the Connecting Party. |
| last-four-digits | Last four digits of Payer bank card number. |
| dest-last-four-digits | Last four digits of customer credit card number. Relevant only for transfer transactions. |
| bin | Bank BIN of Payer bank card number. |
| card-type | Type of Payer bank card (VISA, MASTERCARD, etc). |
| gate-partial-reversal | Processing gate support partial reversal (enabled or disabled). |
| gate-partial-capture | Processing gate support partial capture (enabled or disabled). |
| transaction-type | Transaction type (sale, reversal, capture, preauth). |
| processor-rrn | Bank Receiver Registration Number. |
| processor-tx-id | Acquirer transaction identifier. |
| receipt-id | Electronic link to receipt https://gate.payneteasy.eu/paynet/view-receipt/ENDPOINTID/receipt-id/. |
| name | Payer’s name. |
| card-ref-id | Card reference ID used in subsequent recurrent payments. Relevant only if card-ref-id was created for initial transaction. |
| cardholder-name | Cardholder’s name. |
| card-exp-month | Bank card expiration month. |
| card-exp-year | Bank card expiration year. |
| card-hash-id | Unique card identifier to use for loyalty programs or fraud checks. |
| card-country-alpha-three-code | Three letter country code of source card issuer. See [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| destination-card-country-alpha-three-code | Three letter country code of destination card issuer. See [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| dest-bin | Bank BIN of customer credit card number. |
| dest-card-type | Type of customer credit card (VISA, MASTERCARD, etc). |
| dest-bank-name | Bank name by customer card BIN. |
| destination-hash-id | Unique card identifier to use for loyalty programs or fraud checks. Relevant only for transfer transactions. |
| destination-card-hash-id | Unique card identifier to use for loyalty programs or fraud checks. |
| first-name | Payer’s first name. |
| last-name | Payer’s last name. |
| email | Payer’s e-mail. |
| country \* | Payer’s country (two-letter country code). Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. |
| state \* | Payer’s state . Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Mandatory for USA, Canada and Australia. |
| city \* | Payer’s city. |
| zip_code \* | Payer’s ZIP code. |
| address1 \* | Payer’s address line 1. |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. |
| bank-name | Bank name by Payer card BIN. |
| terminal-id | Acquirer terminal identifier to show in receipt. |
| paynet-processing-date | Acquirer transaction processing date. |
| approval-code | Bank approval code. |
| order-stage | The current stage of the transaction processing. See [Order Stage](https://doc.payneteasy.com/integration/reference/order_stage.html.md) for details. |
| total-reversal-amount | Total amount of processed reversals. Relevant only for reversal transactions. |
| reversal-amount | The amount of the last processed reversal. Relevant only for reversal transactions. |
| auth-response-code | Response code used in Iso8583 protocol. Only returned in specific cases. |
| acquirer-processing-date | Acquirer transaction processing date. |
| processor-auth-credit-code | Approval credit code. Only returned in specific cases. |
| processor-credit-rrn | Retrieval Reference Number for credit transaction. |
| processor-credit-arn | Acquirer card reference number for credit transaction. |
| processor-debit-arn | Acquirer card reference number for debit transaction. |
| loyalty-balance | The current bonuses balance of the loyalty program for current operation. if available. |
| loyalty-message | The message from the loyalty program. if available. |
| loyalty-bonus | The bonus value of the loyalty program for current operation if available. |
| loyalty-program | The name of the loyalty program for current operation if available. |
| descriptor | Bank identifier of the payment recipient. |
| original-gate-descriptor | Descriptor, which is set on gate level in the system. |
| error-message | If status in declined, error, filtered this parameter contains the reason for decline. |
| error-code | The error code is case status in declined, error, filtered. |
| by-request-sn | Serial number assigned to the specific request by gate.payneteasy.eu. If this field exist in status request, status response return for this specific request. |
| verified-3d-status | See [3D Secure Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| verified-rsc-status | Returned if Random Sum Check was performed. See [Alternative cardholder authentication](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) |
| eci | Electronic Commerce Indicator (Visa). |
| ips-src-payment-product-code | Code for card set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-product-name | Decrypted code for card set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-type-code | Type of card code set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-type-name | Decrypted code for type of card set by multinational financial service (Visa/Mastercard). |
| merchantdata | If provided in initial request, merchant_data parameter and its value will be included in status response. |
| initial-amount | Amount, set in initiating transaction, without any fees or commissions. This value can’t change during the transaction flow. |
| seller-commission | Total commission for processed transaction. This is optional parameter. Please contact your manager in Payneteasy, if you would like to receive it. |
| acquirer-commission | Acquirer commission for processed transaction. This is optional parameter. Please contact your manager in Payneteasy, if you would like to receive it. |
| motivational-message | This is an optional message which contains extended information about the reason for the declined transaction. |
| transaction-date | Date of final status assignment for transaction. |
| orig-amount | Contains the original request amount if it was converted on auxiliary endpoint in Parallel form integration. Relevant only for Payment Cashier transactions. |
| orig-currency | Contains the original request currency if it was converted on auxiliary endpoint in Parallel form integration. Relevant only for Payment Cashier transactions. |

#### Pa Req Form Status Response Parameters

| Name | Description |
|------------------------|-----------------------------------------------------------------|
| tds-pareq-form-pareq | ACS 3DS Pa Req data, which received by the Connecting Party. |
| tds-pareq-form-acs-url | ACS URL to redirect the Payer to 3DS 1.0.2 Authentication Flow. |

#### CReq Form Status Response Parameters

| Name | Description |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| tds-creq-form-creq | A CReq message initiates Cardholder interaction in a Challenge Flow and is used to carry authentication data from the Cardholder. It is formed by the 3DS Server and is posted through the Cardholder’s browser by the merchant to the ACS URL. |
| tds-creq-form-acs-url | ACS URL to redirect the Payer for Challenge Flow. |

#### Method Url Frame Status Response Parameters

| Name | Description |
|------------------------------------------|--------------------------------------------------------------------------------------------------------|
| tds-method-url-frame-3ds-server-trans-id | Universally unique transaction identifier assigned by the 3DS Server to identify a single transaction. |
| tds-method-url-frame-3ds-method-url | 3DS Method URL used in iframe form which is provided to Payer browser by the merchant. |

Rules to form the HTML form.

threeDSMethod Data (threeDSMethod NotificationURL + threeDSServer TransID).
 

#### Request Example

```http
POST /paynet/api/v2/status/37211 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.77.0
Accept: */*
Content-Length: 99
Content-Type: application/x-www-form-urlencoded
Connection: close

login=TestYujik
&client_orderid=123
&orderid=6863082
&control=647f0581bbceb804a73e98d9ea7e78640a75bf1c
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 12 Sep 2022 09:02:42 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
X-Cached: EXPIRED
Content-Length: 1275

type=status-response
&serial-number=00000000-0000-0000-0000-000002ddb056
&merchant-order-id=123
&processor-tx-id=PNTEST-6863082
&paynet-order-id=6863082
&status=approved
&amount=555.00
&currency=USD
&descriptor=XXXX
&original-gate-descriptor=XXXX
&gate-partial-reversal=enabled
&gate-partial-capture=enabled
&transaction-type=sale
&receipt-id=081c0c0b-0dd1-3083-b251-e624ac8e57b4
&name=CARD+HOLDER
&cardholder-name=CARD+HOLDER
&card-exp-month=12
&card-exp-year=2099
&email=john.smith%40gmail.com
&last-name=Smith
&first-name=John
&processor-rrn=0225083062885
&approval-code=979249
&order-stage=sale_approved
&merchantdata=VIP+customer
&last-four-digits=2063
&bin=410002
&card-type=VISA
&phone=12063582043
&bank-name=BANCO+ITAUCARD+S.A.
&auth-response-code=00
&terminal-id=12345678
&paynet-processing-date=2022-09-07+13%3A22%3A39+MSK
&acquirer-processing-date=2022-09-07+13%3A22%3A39+MSK
&processor-auth-credit-code=206551
&card-hash-id=2639503
&card-country-alpha-three-code=BRA
&verified-3d-status=NOT_AUTHENTICATED
&processor-credit-rrn=0225060914211
&processor-credit-arn=809124106
&processor-debit-arn=601904020
&purpose=user_account1
&ips-src-payment-product-code=F
&ips-src-payment-product-name=Visa+Classic
&ips-src-payment-type-code=Credit
&ips-src-payment-type-name=VISA+Credit
&initial-amount=555.00
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 12 Sep 2022 09:08:02 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
X-Cached: MISS
Content-Length: 137

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddb057
&error-message=End+point+with+id+372118+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/status/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v2/void

#### Introduction

Void can only be processed for Sale and Capture transactions in the final successful status (See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md)). To make a void request send an HTTPS POST request to the [URLs](#api-v2-void-request-url) and the [parameters](#api-v2-void-request-parameters-url). Use [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------|--------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/void/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v2/void/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v2/void/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v2/void/void/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded.

> **Warning:** The following characters must be escaped in the parameter values: & + “.

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| login | Connecting Party login name. | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| orderid | Unique order identifier assigned by Payneteasy system. | `Necessity`: Mandatory `Type`: String `Length`: 20 |
| client_orderid | Unique Connecting Party identifier. | `Necessity`: Mandatory `Type`: Numeric `Length`: 10 |
| amount | This optional parameter specifies amount to be reversed. | `Necessity`: Mandatory `Type`: String `Length`: 10 |
| currency | Currency the transaction is charged in (See: [Currency codes](https://doc.payneteasy.com/integration/reference/currency_codes.html.md)). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Conditional `Type`: String `Length`: 3 |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Request parameter: login 2. Request parameter: client_orderid 3. Request parameter: orderid 4. merchant_control (Control key assigned to Connecting Party account in the Payneteasy gateway system). | `Necessity`: Conditional `Type`: String `Length`: 128 |
| comment | A brief description of reason. | `Necessity`: Mandatory `Type`: String `Length`: 50 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter Name | Description |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| end-point-id | Entry point used for processing this transaction. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v2/void/39914 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 123
Content-Type: application/x-www-form-urlencoded
Connection: close

login=Test
&client_orderid=55
&orderid=6862995
&comment=Service not provided
&control=246e0a2074f9e4b84cff59b2567ed48ec3aab87d
```

#### Success Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Tue, 16 Aug 2022 06:57:40 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 138

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddae76
&merchant-order-id=55
&paynet-order-id=6862995
&end-point-id=39914
```

#### Fail Response Example

```http
HTTP/1.1 200 OK
Server: server
Date: Tue, 16 Aug 2022 07:21:37 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 148

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddae78
&merchant-order-id=Test
&error-message=INVALID_CONTROL_CODE
&error-code=2
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v2/void/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/create-card-ref

#### Introduction

Card reference ID and Recurring Payment ID creation is initiated through HTTPS POST request by using [URLs](#api-v4-card-ref-id-request-url) and the [parameters](#v4-card-ref-id-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/create-card-ref/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/create-card-ref/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/create-card-ref/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/create-card-ref/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Sale Request Parameters | Description |
|---------------------------|---------------------------------------------------------------------|
| login | Connecting Party’s login name. |
| client_orderid | Connecting Party’s order identifier of the transaction. |
| orderid | Transaction order identifier assigned by Payment Gateway. |

Connecting Party has to supply orderid and client_orderid associated with the first payment transaction. It emphasizes that the first payment is a mandatory step to process recurring payments. To authorize the credit card the information about it must be sufficient and an initial payment must be in [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Registration Response Parameter | Description |
|-----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be create-card-ref-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| card-ref-id | Card reference ID used in subsequent recurring payments. |
| unq-card-ref-id | Unique card reference ID to each PAN. It can be used by Connecting Party for loyalty programs or fraud control. |
| recurring-payment-id | Payer’s tokenized cardholder’s data ID, referred as Recurring Payment ID (RPI). |
| dst-card-ref-id | Receiver’s card reference ID used in subsequent recurring payments. Can be used only in transfer APIs. |
| dst-unq-card-ref-id | Receiver’s unique card reference ID to each PAN. It can be used by Connecting Party for loyalty programs or fraud control. Can be used only in transfer APIs. |
| dst-recurring-payment-id | Receiver’s tokenized cardholder’s data ID, referred as Recurring Payment ID (RPI). Can be used only in transfer APIs. |
| error-message | If status is declined or error this parameter contains the reason for decline. |
| error-code | The error code is case of declined or error status. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |

#### Request Example

```http
POST /paynet/api/v4/create-card-ref/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="KT6cZmuVGqg0V6Jm2RE3q4o79KXC1v2q", oauth_signature="KucF0eYk3WZCV7oKwOi1z6PR%2BkHxiZwPucD6Sx%2BX2mV%2BbaidPy9K9USh8ciMKM60NNl1LYYjywdaErB1uTIdFFbQ8ZKs8M1smaMPOaHDaApceTOlDh6E7u3BzBTKYhBc%2BWnksZz9Wyz8%2B39lHCIODo0KZmNmXCTjjZmlx%2FrFNkK%2FhwJV9Kwq1nPbA5QZTkF686O0O0lHFy3Prx649AIRgsrqDLb5%2FgHL9M8fSScVUPnGdLGJ2hSgKJFpIOFibT0nC89Xg8odn1hR9WIa1650glaqZntSkocBzXAkOKa7kIbSOZW1sFCiBjksy6o1sny9hmc%2F9cC9t86RoEY1QhVYuvOLztQm1dLhpRy%2FPOL9LCmIzO3B%2FUB2wJUXPkEyFsSLZVeqQl%2B0IukljV6Cr1ZfuyUktbvvXJsnod5AK%2FsV2GaxEf%2BttqqWv%2FFNjPLoUZYrPB6rKsIpw%2FOftinIwIxYzLY3FMmbKQd6zxnMJLJm7M2s6cQFGiAnfgvZFAMZhugBuuigy4T9Ckq1t5N9vQkl2htDv0TTnswx50wpF%2F7OKiXTVFNqOE%2FCj%2F07ZwZbxbD%2FMxKhOhfNMME1jGxzgI0wEj1166eKpxnCOk%2BTlYTJvNW5%2BbKuGnU43Q2Nmga0aQ007NKRfIV%2FWk6e%2BUuGO48wGdi0CiKxS9hpnpvjyPLc%2BsA%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1673335450", oauth_version="1.0"
Content-Length: 40
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=34T43R77N
&orderid=6868305
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Tue, 10 Jan 2023 07:24:36 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 174

type=create-card-ref-response
&serial-number=00000000-0000-0000-0000-000002de3113
&card-ref-id=1461608
&recurring-payment-id=1491863
&dst-card-ref-id=1461608
&status=approved
```

#### Fail Response Example

```http
HTTP/1.1 403
Server: server
Date: Tue, 10 Jan 2023 07:34:08 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>403</title>

    
</head>

<body>
    <p>Access is denied</p>
</body>
</html>
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/create-card-ref/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/create-recurring-payment

#### Introduction

/api/v4/create-recurring-payment is a synchronous API command. If request is accepted with no errors, the Payment Gateway creates a recurring payment profile and assigns a new recurring-payment-id to it. The recurring transactions will be processed according to the created recurring payment profile using the payment data saved in this profile.
 
Create recurring payment is initiated through HTTPS POST request by using [URLs](#api-v4-create-recurring-payment-request-url) and the [parameters](#api-v4-create-recurring-payment-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/create-recurring-payment/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/create-recurring-payment/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

> **Note:** If the recurrent has switched to Stopped, you can update its schedule using the start-date and finish-date parameters. However, it can only be resumed via the UI by clicking on Resume.

Type native on UI means that The recurring payment setup and the actual charges are in the same acquirer.
 
To create recurring payment profile with automatic recurring schedule, send interval and period parameters. To create recurring payment profile without automatic recurring schedule, do not send interval and period parameters. To stop the automatic recurring schedule, use [/api/v4/update-recurring-payment](https://doc.payneteasy.com/integration/api_v4_update-recurring-payment.html.md). Available only for SRC.
 

| Parameter Name | Description | Value |
|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| rp_card_type | SRC - Sender’s source card. DST - Receiver’s destination card. | `Necessity`: Required `Type`: Enum `Length`: 3 |
| client-orderid | Connecting Party order ID. Supported for SRC and DST type. | `Necessity`: Required `Type`: String `Length`: 128 |
| credit-card-number | Payer\`s credit card number. Supported for SRC and DST type. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| cvv2 | Payer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number printed on the back of the card in the signature area. | `Necessity`: Optional `Type`: Numeric `Length`: 3-4 |
| card-printed-name | Payer\`s card printed name. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire-year | Payer\`s card expire year. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| expire-month | Payer\`s card expire month. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| currency | Currency type. Supported for SRC and DST type. | `Necessity`: Required `Type`: String `Length`: 3 |
| country | Payer\`s country. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 2 |
| city | Payer\`s city. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| zip-code | Payer\`s zip-code. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 10 |
| address1 | Payer\`s address. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 256 |
| first-name | Payer\`s first-name. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| last-name | Payer\`s last-name. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| email | Payer\`s email. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| amount-from | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-to | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-sequence | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0. Supported for SRC and DST type. Required if amount-from and amount-to or amount are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| period | Possible values are: day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| interval | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: Int `Length`: - |
| order_desc | Description of Recurring payment. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 65K |
| customer-ip | Payer\`s IP address. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 45 |
| ssn | Social security number field. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 32 |
| birthday | Payer\`s birthday date. Not supported for DST. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| phone | Payer\`s phone number. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| start-date | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today. Supported for SRC and DST type. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| finish-date | Date, when the Payer will be charged last time. Supported for SRC and DST type. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| max-repeats-number | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made (unless done manually), even if a recurring payment is stopped and rescheduled again. Supported for SRC and DST type. | `Necessity`: Optional `Type`: Int `Length`: - |
| purpose | Purpose of transaction. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | Notify url field. server_callback_url parameter can also be used. For more information please see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | Connecting Party URL which will receive callback request once the transaction reaches final status. Connecting Party may use Server Callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. See callback details in [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Send either notify_url or server_callback_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

> **Warning:** /api/v4/create-recurring-payment is a synchronous API command. The response will be returned after the recurring payment profile will be created on Payment Gateway side.

| Response Parameters | Description |
|-----------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be create-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| recurring-payment-id | Recurring ID assigned to the order by Payneteasy. |
| status | If request is accepted, this parameter has approved value. This is not a transaction status. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is declined or error this parameter contains the reason for decline or error details. |
| error-code | The error code in case of declined or error status. |

#### Request Example

```http
POST /paynet/api/v4/create-recurring-payment/ HTTP/1.1
User-Agent: curl/8.4.0
Accept: */*
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant", oauth_nonce="qdyD66xc8sDEQwo3r12VjJfJhAOXuj6O", oauth_signature="eZve%2FSvPCTBXtQM%2BEwTEROtsQE27gZJr36EThL8ECCrnWH9Xw8JxcysNEPTG5HfcYwR2IOjDk3uiSNFa1oT2bQT9XONQTl1JVTOhIiMrMJT7GT1rGuLSsEvghaBoRLrcth6SC0c%2F%2FINyOxmIc%2B79E3T8hkpH6J6VI%2BSRG162%2BlHBPc1u1SGGnhkkRYU621AUGu2FDrc4neob4QJSm%2BaF3a0AgWDGiLbeQ0Ivn3YJ441EKd99kBWdaCuUp0eSfcmh3U2Js66edCjWXDEW7uuywP%2BU%2FBEeq06XxoVNGE2NF2LArXgoNqfzz2Tpisq35%2FE7Yg%2F9hphww75HMoJCECe0yVIHmKXd8HBDNMyT7gg3w5bnKbo%2FURX0m%2Fpe7bxkJ1mLNsKouHVkvjLZKpWVVUyCl%2BJ3x0BoEN5QK7xh0fNbV4Ue9TUOz59q0v%2B7lz5E1B4TvxQ9pa%2FmNCl4P2JgTosLvXNcdGn9Dq0TC0gb62O2W81MoZAljJQew%2FcKAUFTXBMZK6eIXzA81BPQVejv8nIVsvHKNo2Ko0s3hJPKGaeVAN0gyUAPw0%2BsJI3bnN2CPSW92xysGRWJYBtsHhqDhmgtoDNvw7LFB6BzRk5GPa9iQju34l47GsCUUIs3%2ByipIl7Q3HnM%2Bet9L8JSl7K02MwR6zlLxtd9UXHDq3pnmKzly6I%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1721312072", oauth_version="1.0"
Content-Length: 595
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

address1=1234%20Peace%20street
&amount=55
&birthday=1980-01-02
&card-printed-name=JOHN%20SMITH
&city=Chicago
&client-orderid=1575634981130
&country=US
&credit-card-number=4464920026265488
&currency=USD
&customer-ip=1.2.3.4
&cvv2=123
&email=john.smith%40example.com
&expire-month=12
&expire-year=2040
&finish-date=2040-01-01
&first-name=John
&interval=1
&last-name=Smith
&max-repeats-number=1000
&notify-url=http%3A%2F%2Fexample.com%2Fnotify-me
&order_desc=testing%20purposes
&period=week
&phone=12345678
&purpose=No%20purpose%20at%20all
&rp_card_type=SRC
&ssn=1234
&start-date=2030-01-01
&state=IL
&zip-code=123456
&server_callback_url=https://httpstat.us/200
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 18 Jul 2024 14:16:20 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=create-recurring-payment-response
&serial-number=00000000-0000-0000-0000-000002f36d81
&recurring-payment-id=1492124
&status=approved
```

#### Fail Response Example

```http
HTTP/1.1 500
Server: server
Date: Thu, 18 Jul 2024 14:24:28 GMT
Content-Length: 61
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [8485772c-21d6-42aa-b2eb-3b5ae4e07d19]
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/create-recurring-payment/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/create-recurring-payments

#### Introduction

If request is accepted with no errors, the Payment Gateway creates separate recurring payment profiles for each entry provided in the request and assigns new recurring-payment-id to each of them. The recurring transactions will be processed according to the created recurring payment profiles using the payment data saved in each profile.
 
Create recurring payments Multiple is initiated through HTTPS POST request by using [URLs](#api-v4-create-recurring-payments-request-url) and the [parameters](#api-v4-create-recurring-payments-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------------|-------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/create-recurring-payments/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/create-recurring-payments/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Below is a description of each parameter that can be included in the CSV and added to payload parameter which will be used in the request.
 
The recurring payment profile details can be viewed only via UI.
 

> **Note:** If the recurrent has switched to Stopped, you can update its schedule using the start-date and finish-date parameters. However, it can only be resumed via the UI by clicking on Resume.

Type native on UI means that The recurring payment setup and the actual charges are in the same acquirer.
 
To create recurring payment profile with automatic recurring schedule, send interval and period parameters. To create recurring payment profile without automatic recurring schedule, do not send interval and period parameters. To stop the automatic recurring schedule, use [/api/v4/update-recurring-payments](https://doc.payneteasy.com/integration/api_v4_update-recurring-payments.html.md). Available only for SRC.
 

| CSV Parameter Name | Description | Value |
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| rp_card_type | SRC - Sender’s source card. DST - Receiver’s destination card. | `Necessity`: Required `Type`: Enum `Length`: 3 |
| client-orderid | Connecting Party order ID. Supported for SRC and DST type. | `Necessity`: Required `Type`: String `Length`: 128 |
| credit-card-number | Payer\`s credit card number. Supported for SRC and DST type. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| cvv2 | Payer’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number printed on the back of the card in the signature area. | `Necessity`: Optional `Type`: Numeric `Length`: 3-4 |
| card-printed-name | Payer\`s card printed name. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire-year | Payer\`s card expire year. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| expire-month | Payer\`s card expire month. Required for SRC, optional for DST. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| currency | Currency type. Supported for SRC and DST type. | `Necessity`: Required `Type`: String `Length`: 3 |
| country | Payer\`s country. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 2 |
| city | Payer\`s city. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| zip-code | Payer\`s zip-code. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 10 |
| address1 | Payer\`s address. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 256 |
| first-name | Payer\`s first-name. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| last-name | Payer\`s last-name. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| email | Payer\`s email. Not supported for DST. | `Necessity`: Required `Type`: String `Length`: 128 |
| amount-from | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-to | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-sequence | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0. Supported for SRC and DST type. Required if amount-from and amount-to or amount are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| period | Possible values are: day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| interval | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: Int `Length`: - |
| order_desc | Description of Recurring payment. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 65K |
| customer-ip | Payer\`s IP address. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 45 |
| ssn | Social security number field. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 32 |
| birthday | Payer\`s birthday date. Not supported for DST. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| phone | Payer\`s phone number. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| start-date | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today. Supported for SRC and DST type. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| finish-date | Date, when the Payer will be charged last time. Supported for SRC and DST type. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| max-repeats-number | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made (unless done manually), even if a recurring payment is stopped and rescheduled again. Supported for SRC and DST type. | `Necessity`: Optional `Type`: Int `Length`: - |
| purpose | Purpose of transaction. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | Notify url field. server_callback_url parameter can also be used. For more information please see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | Connecting Party URL which will receive callback request once the transaction reaches final status. Connecting Party may use Server Callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. See callback details in [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Send either notify_url or server_callback_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be create-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. Multiple error codes may be received: 200, 403, and 500. For the 500 error code, an additional error ID will be returned. |
| recurring-payment-id | Recurring ID assigned to the order by Payneteasy. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |

#### Request Example

**Step 1.** Create a CSV with the provided structure:
 
```http
"client-orderid";"rp_card_type";"payment-description";"first-name";"last-name";"address1";"city";"zip-code";
"country";"state";"phone";"email";"customer-ip";"period";"interval";"start-date";"finish-date";"max-repeats-number";"amount";
"amount-from";"amount-to";"amount-sequence";"currency";"card-printed-name";"credit-card-number";"expire-month";"expire-year"
```

**Step 2.** Encode CSV to base64 with the following command:
 
```bash
base64 create-recurring-payments-example.csv
```

**Step 3**. Assign the base64 encoded value to payload parameter and send the request:
 
```http
POST /paynet/api/v4/create-recurring-payments/ HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/8.4.0
Accept: */*
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant",oauth_signature_method="RSA-SHA256",oauth_timestamp="1727178538",oauth_nonce="cdtNANOCATq",oauth_version="1.0",oauth_signature="B5m%2FOQOSBgqWI%2F%2FG3GhZw2kCJZDda7J6fLpOu6wFyBEj60PJp5u1mqBnIufzkkmrSkyZkCT6v12WIhwE%2BWTtJ7Wg%2BRx9cqXPfhk5JhQpnofsVheXpCpftoLvvBTqn8p67WaS%2B6kfzGtGhdXHYVBzIxXDxabnMjMC8u8EtfWsovzTp%2BAYfZKn2H0qH7B62dfUW4PuRCTmy9svbwLhbPULkh3oJ3a1M%2BnRqXIasIrd3WY1MD9lkqUetAtW3xIWnOoMvPZ0wzk2UEbU%2BoZ2KTiA9KO09%2Ffq7OylRhiDpqtz65EMBiKujFFSF42bzYsB1SmPssk09xJoWmsNR9tFZsdx2Hgl7yFZTXhxV3nlSZTGDVZaVe2pPSi8va5W9yTlPMPU5HcNE5MuZ3T9PSEURQvM691UcPSdlJAi8q7B0EhXDzwOlgLV7DsFDtpsXSeXopFpG6uHiNPIjW65p6XFQ31xr4foZCahVeymuIoiXE6uAkHJJ89oHqKsOBnI7xILu2UpflHnl7gn%2BvX9IWdUHx1xEMdBPWdUQRFNllGvT2N8nYrtZe96L%2BfwxarYR2Fh1LtyqwCtEXhQm5jhjpR3NQpqddY3NSd75NUP7zlDQwXCknMQps6uSdng9Uv%2B7IFx3oNUfjVMxp4CGcmEtSxH7Ykx8dX5srNOKLDJT5tyExLLjXk%3D"
Content-Length: 754
Connection: keep-alive

payload=Y2xpZW50LW9yZGVyaWQ7cnBfY2FyZF90eXBlO29yZGVyX2Rlc2M7Zmlyc3QtbmFtZTtsYXN0LW5hbWU7YWRkcmVzczE7Y2l0eTt6aXAtY29kZTtjb3VudHJ5O3N0YXRlO3Bob25lO2VtYWlsO3BlcmlvZDtpbnRlcnZhbDtzdGFydC1kYXRlO2ZpbmlzaC1kYXRlO21heC1yZXBlYXRzLW51bWJlcjthbW91bnQ7YW1vdW50LWZyb207YW1vdW50LXRvO2Ftb3VudC1zZXF1ZW5jZTtjdXJyZW5jeTtjYXJkLXByaW50ZWQtbmFtZTtjcmVkaXQtY2FyZC1udW1iZXI7ZXhwaXJlLW1vbnRoO2V4cGlyZS15ZWFyO2N2djI7cHVycG9zZTtub3RpZnktdXJsO3NzbjtiaXJ0aGRheQ0KMTIzNDU2Nzg5MDtTUkM7O1dpbGw7U3RpbGw7MTIzNCBSZWluO1JlaW1zOzEyMzQ1NjtGUjtCUkU7MTIzNDU2Nzg7d2lsbHN0aWxsQGV4YW1wbGUuY29tO3dlZWs7MTsxNi4wOS4yMDI0OzE3LjA5LjIwMjQ7MTAwMDsxMDs7OztVU0Q7V0lMTCBTVElMTDs0NDU4MjA0NjgxMzg3MDUzOzEyOzIwNDA7MTIzO05vIHB1cnBvc2UgYXQgYWxsO2h0dHA6Ly9leGFtcGxlLmNvbS9jcmVhdGUtbWU7MTIzNDsyMi4wMS4xOTgwDQo%3D
```

#### Success Response Example

> **Note:** The successful response has empty body and HTTP code 200.

```http
HTTP/1.1 200
Server: server
Date: Tue, 24 Sep 2024 09:44:01 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
```

#### Fail Response Example

> **Note:** The unsuccessful response has empty body and HTTP code 403.

```http
HTTP/1.1 403
Server: server
Date: Wed, 25 Sep 2024 08:45:42 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
```

### /api/v4/transfer-by-ref

#### Introduction

Deposit to card transfer (D2C) is a money transfer from Connecting Party bank account (Deposit) and Receiver bank card number (PAN) or tokenized card data (Card Reference ID). Deposit to card is initiated through HTTPS POST request by using [URLs](#api-v4-transfer-by-ref-url) and the [parameters](#api-v4-transfer-by-ref-request) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer-by-ref/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/transfer-by-ref/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer-by-ref/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/transfer-by-ref/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Parameters marked as Conditional\* can be mandatory for specific integrations. For more information, please contact your manager in Payneteasy.
 

| Parameter Name | Description | Value |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party order identifier. | `Necessity`: Required `Type`: String `Lenght`: 128 |
| login | Connecting Party’s login. Must be used as oauth_consumer_key in OAuth Authorization, not included in request as login parameter. | `Necessity`: Required `Type`: String `Lenght`: 20 |
| destination-card-no | Card number of destination card. Mandatory if destination-card-ref-id omitted. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Conditional `Type`: String `Lenght`: 16-19 |
| destination-card-ref-id | Card reference id to destination card, obtained at Card Registration step. Mandatory if destination-card-no omitted. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Conditional `Type`: Numeric `Lenght`: 20 |
| destination_expire_month | Expire month of destination card. | `Necessity`: Conditional `Type`: String `Lenght`: 1-2 |
| destination_expire_year | Expire year of destination card. | `Necessity`: Conditional `Type`: String `Lenght`: 2-4 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Lenght`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Lenght`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Lenght`: 64k |
| receiver_identity_document_series | Receiver’s identity document series (e.g. 4 digits for domestic passport). | `Necessity`: Optional `Type`: String `Lenght`: 512 |
| receiver_identity_document_number | Receiver’s identity document number (e.g. 6 digits for domestic passport). | `Necessity`: Optional `Type`: String `Lenght`: 512 |
| receiver_identity_document_id | Receiver’s identity document id. Possible values: 21 for domestic passport or 31 for international passport. | `Necessity`: Optional `Type`: String `Lenght`: 512 |
| receiver_address1 | Receiver’s address. | `Necessity`: Conditional\* `Type`: String `Lenght`: 512 |
| receiver_city | Receiver’s city. | `Necessity`: Conditional\* `Type`: String `Lenght`: 512 |
| receiver_first_name | Receiver first name. | `Necessity`: Required `Type`: String `Lenght`: 128 |
| receiver_middle_name | Receiver middle name. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| receiver_last_name | Receiver last name. | `Necessity`: Required `Type`: String `Lenght`: 128 |
| receiver_phone | Receiver full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| receiver_resident | Is receiver a resident? | `Necessity`: Optional `Type`: Boolean `Lenght`: true/false |
| ipaddress | Customer’s IP address, included for fraud screening purposes. | `Necessity`: Optional `Type`: String `Lenght`: 45 |
| first_name | Sender first name. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| middle_name | Sender middle name. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| last_name | Sender last name. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| ssn | Last four digits of the Sender’s social security number. | `Necessity`: Optional `Type`: Numeric `Lenght`: 32 |
| birthday | Sender date of birth, in the format MMDDYY. | `Necessity`: Optional `Type`: Numeric `Lenght`: 8 |
| address1 | Sender address line 1. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Lenght`: 256 |
| city | Sender city. | `Necessity`: Optional `Type`: String `Lenght`: 50 |
| state | Sender’s state. Please see Appendix A for a list of valid state codes. Mandatory for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Lenght`: 2-3 |
| zip_code | Sender ZIP code. | `Necessity`: Optional `Type`: String `Lenght`: 10 |
| receiver_zip_code | Receiver ZIP code. | `Necessity`: Conditional\* `Type`: String `Lenght`: 10 |
| country | Sender country (two-letter country code). Please see Appendix B for a list of valid country codes. | `Necessity`: Optional `Type`: String `Lenght`: 2 |
| receiver_country_code | Receiver country (two-letter country code). Please see Appendix B for a list of valid country codes. | `Necessity`: Optional `Type`: String `Lenght`: 2 |
| phone | Sender full international phone number, including country code. | `Necessity`: Optional `Type`: String `Lenght`: 15 |
| cell_phone | Sender full international cell phone number, including country code. | `Necessity`: Optional `Type`: String `Lenght`: 15 |
| email | Sender email address. | `Necessity`: Optional `Type`: String `Lenght`: 50 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Parties who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; mail@example.com etc. This value will be used by fraud monitoring system. | `Necessity`: Optional `Type`: String `Lenght`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. See more details at [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). | `Necessity`: Optional `Type`: String `Lenght`: 250 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. | `Necessity`: Optional `Type`: String `Lenght`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. | `Necessity`: Optional `Type`: String `Lenght`: 1024 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Lenght`: 64k |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response parameter | Description |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v4/transfer-by-ref/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="w1rmMzx2Sq2k5Hi7KAZmdhHHD6BygKcE", oauth_signature="rXn0DwLOlaV%2Ft1q3s%2FJdLybJTdxKKN0XeFtyVNZ0U5bG0Qfcc6iyHqQG66Ohb852CYKjhrxvG3wf33RlIQdO9f23OSg91JkdrUgl8QDrMqntC5myWGR1woums%2BMjpV821fAY8AS%2BBByNUKOuC1mwFgLYwr5YinbhjDa6P8aEdHgbf%2FVw5vg9OqjwKxJhSXPGB5mIg7T9gTNXF4n4YTUJA0l%2BWyeGcIjuTSsiCUnbsrNjBOGYc0PlUSuHirwJ0NiKVdHk3qaZrGaEw8SZEq%2F8x0naoaaOXUq%2FkpqPfTJT%2FjTl%2FbGyX1x%2FwTl6EYgIElavHYj2psIGmFnyUk%2FYnaGZHikE00rSf4IkG5Ye2M4hyl7lKQOCXMZMvvGtfvLm0RsAod8o30KuDD5Tw%2BRmDiQNCqN8GeZawHsZipgwZuy2IdZ3sHiot3U6NEt1OVH9TsWDU%2FstfBJOWBBStTRTTh4hn3Zvf5jLuTfTcepKz4CIgdQGGmMmRSz6dcBnkYJaa7VRTh27dz%2BnEuC0laEYAytVuzQA43MvUXNLmAuh9JlmqQquAZwB%2BRFfLPgOj%2FVVsFsqX35UWBYQtWlWdEVc3jWBVxCjEW0s8cAcowlb4R2g4V48HC2Rz3ggfINzP9%2FWtX1nkNnIlzQAeYbMREguYqFrK%2BYK6Lqyu%2BM1jeo6j9CWhhk%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1697442690", oauth_version="1.0"
Content-Length: 805
Content-Type: application/x-www-form-urlencoded
Connection: close

address1=10020Main%20st
&amount=100
&birthday=19820115
&cell_phone=%2B19023384543
&city=Seattle
&client_orderid=34T43R77N
&country=US
&currency=USD
&destination-card-ref-id=1461819
&card-exp-month=07
&card-exp-year=2028
&email=john.smith%40gmail.com
&first_name=John
&ipaddress=65.153.12.232
&last_name=Smith
&merchant_data=VIP%20customer
&middle_name=M
&order_desc=Test%20Order%20Description
&phone=%2B12063582043
&purpose=user_account1
&receiver_address1=Red%20Sq%2C%201a
&receiver_city=Moscow
&receiver_first_name=Jane
&receiver_identity_document_id=21
&receiver_identity_document_number=222222
&receiver_identity_document_series=1111
&receiver_last_name=Doe
&receiver_middle_name=L
&receiver_phone=%2B79031110022
&receiver_resident=true
&redirect_url=http%3A%2F%2Fwww.example.com%2F
&server_callback_url=https%3A%2F%2Fhttpstat.us%2F200
&ssn=1267&state=WA
&zip_code=98102
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 16 Oct 2023 13:20:25 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 145

type=async-response
&serial-number=00000000-0000-0000-0000-000002ee3a57
&merchant-order-id=34T43R77N
&paynet-order-id=7234671
&end-point-id=39915
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 16 Oct 2023 07:54:11 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 162

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ee3a4f
&merchant-order-id=34T43R77N
&error-message=Rebill+1461819+was+not+found
&error-code=104
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/transfer-by-ref/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/payout-by-ref/

#### Introduction

Payout By Reference is initiated through HTTPS POST request by using [URLs](#payout-by-ref-api) and the [parameters](#payout-by-ref-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/payout-by-ref/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/payout-by-ref/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/payout-by-ref/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/payout-by-ref/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

> **Note:** Ask Support Manager if Conditional fields are Required for integration.

| Parameter Name | Description | Value |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party’s order identifier. | `Necessity`: Required `Type`: String `Length`: 128 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| destination-card-ref-id | Card reference id to destination card, obtained at Card Registration step. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Numeric `Length`: 20 |
| order_desc | Brief order description. | `Necessity`: Optional `Type`: String `Length`: 64 |
| ipaddress | Receiver’s IP address (IPv4 or IPv6). | `Necessity`: Conditional `Type`: String `Length`: 7-45 |
| purpose | Payout purpose. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL, where the Receiver is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return Receiver anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_success_url | URL, where the Receiver is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Receiver anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Receiver is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if there is no need to redirect Receiver anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| account_number | Account Number. | `Necessity`: Conditional `Type`: String `Length`: 24 |
| account_name | Bank account. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ewallet_type | Type of e-wallet. | `Necessity`: Conditional `Type`: String `Length`: 64 |
| ewallet_wallet | E-wallet ID. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| crypto_wallet_address | Address of crypto wallet. | `Necessity`: Conditional `Type`: String `Length`: 64 |
| bank_name | Bank Name. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_branch | Bank Branch Name. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_code | Bank code. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| bank_city | Bank city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| bank_address1 | Bank address. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_zip_code | Bank postal ZIP code. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_province | Bank province. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_area | Bank area. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| routing_number | Routing number used to identify specific bank branches in China. | `Necessity`: Conditional `Type`: String `Length`: 16 |
| legal_person_name | Name on the legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| legal_person_document_number | Number of legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_first_name | Receiver first name, also can be sent as first_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_last_name | Receiver last name, also can be sent as last_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_birthday | Receiver birthday, also can be sent as birthday. | `Necessity`: Conditional `Type`: Numeric `Length`: 30 |
| receiver_country_code | Receiver country code, also can be sent as country. | `Necessity`: Conditional `Type`: String `Length`: 3 |
| receiver_state | Receiver state, should be provided for countries that have states (USA, Canada, Australia), also can be sent as state. | `Necessity`: Conditional `Type`: String `Length`: 4 |
| receiver_city | Receiver city, also can be sent as city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_zip_code | Receiver zip code, also can be sent as zip_code. | `Necessity`: Conditional `Type`: Numeric `Length`: 32 |
| receiver_address1 | Receiver address, also can be sent as address1. | `Necessity`: Conditional `Type`: String `Length`: 256 |
| receiver_phone | Receiver phone, also can be sent as phone. | `Necessity`: Conditional `Type`: Numeric `Length`: 128 |
| receiver_email | Receiver E-mail, also can be sent as email. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_id | Receiver identity document identifier, also can be sent as identity_document_id. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_number | Receiver identity document number, also can be sent as identity_document_number. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64k |
| bank_bic | BIC of the receiver’s bank. | `Necessity`: Optional `Type`: String `Length`: 128 |
| receiver_inn | Receiver’s INN. | `Necessity`: Optional `Type`: String `Length`: 128 |
| customer_level | Customer level in CMS system | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode) | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Merchant Customer ID in CMS system. Required if transaction goes via CMS (CRM mode) | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| card-ref-id | Card reference ID used in subsequent recurring payments. Card reference ID can be created with [v4 tokenization request](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) or [v2 tokenization request](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Necessity`: Conditional `Type`: Long |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Payout Request Parameters | Description |
|-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v4/payout-by-ref/121799 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/8.4.0
Accept: */*
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant", oauth_nonce="8qsDrhiDelGHlxY01aDjCh44u7isXJjL", oauth_signature="WpbNcRxNSDW%2BdJgftRc%2BAN0oe8KAP4CNpUkxjxStFYZEU9Vo%2F7uk9dSKEG%2B76C%2FdlzemILaRmikQqZg93ZK1cibT8zy97uYVDdWVmY2obDSOVb8UipGjt2KFUyKr4awHW9xH%2BTzbR%2FMXwm3y%2Fx2RotElZWxumsL37P5Q%2BCquoAGcO6jjkvkkSH9P4lBYKSmwhfqD4O%2Br8FB3exzNzl2FFBTwLp4ch2G9Cis5a0CkVrpjDB%2FbbbrOutbNPZYhtH45rNz91QAbpvNJ91XjVwxiCm4lCldIO66gF73GQNSFKVG1mstc%2B941Dj1bVhXWQQW%2F9TyPiXfWGP8szg18rwsTHbj1zKCRIaw%2FqVbrOBPhbo%2BJjGMZp2hB1ei0%2FUPIkjeIZkWD2NgJRQEniJfjU7AlILs91augm50fPwWR5JiOuE5uSvwM6VWgXMpYe4USb819ZAK%2BFYTRI%2BenrycFZHmY%2BafOlaOHFtpnbn8FsrzzNbOvGXmXCt2xXAQTaORqMeLRRtkD3DY4rJa8qeO0zYnmT4ZhKsFZjImDdonA3WTG8G7awP9W0RKhHlUGwGaugRWbdPjSbGMhAzs58Y9ptvExr6GwAHhJU1RbzfWL4wCzVbH8%2BAC6I0OrkB13tw2eXP4yIPtEC7iGu%2FkElGz4OrwFEU6cUcEDpeEOmA2%2Fe%2BZFK0w%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1721975900", oauth_version="1.0"
Content-Length: 74
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

amount=10.42
&client_orderid=1
&currency=USD
&destination-card-ref-id=1461897
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 26 Jul 2024 06:39:23 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 138

type=async-response
&serial-number=00000000-0000-0000-0000-000002f36e41
&merchant-order-id=1
&paynet-order-id=7363634
&end-point-id=121799
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 26 Jul 2024 06:42:43 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 170

type=validation-error
&serial-number=00000000-0000-0000-0000-000002f36e42
&error-message=Project+with+currency+USD+does+not+apply+request+with+currency+AZN
&error-code=16
```

### /api/v4/payout

#### Introduction

Payout is initiated through HTTPS POST request by using [URLs](#payout-apis) and the [parameters](#payout-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------|-----------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/payout/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/payout/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/payout/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/payout/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| client_orderid | Connecting Party’s order identifier. | `Necessity`: Required `Type`: String `Length`: 128 |
| amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Sample values are: USD for US Dollar EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Brief order description. | `Necessity`: Optional `Type`: String `Length`: 64 |
| ipaddress | Receiver’s IP address (IPv4 or IPv6). | `Necessity`: Conditional `Type`: String `Length`: 7-45 |
| purpose | Payout purpose. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL, where the Receiver is redirected to upon completion of the transaction. Please note that redirection is performed in any case, no matter whether transaction is approved, declined in any other final [status](https://doc.payneteasy.com/integration/reference/statuses.html.md). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if you have no need to return Receiver anywhere. Use either redirect_url or combination of redirect_success_url and redirect_fail_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_success_url | URL, where the Receiver is redirected to when transaction status is approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Otherwise put https://doc.payneteasy.com if there is no need to redirect Receiver anywhere. Use either combination of redirect_success_url and redirect_fail_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL, where the Receiver is redirected to when transaction status is not approved (See [status list](https://doc.payneteasy.com/integration/reference/statuses.html.md)). Connecting Party must not use the parameters come along with the redirect HTTP Request to treat the status of the transaction. Instead Connecting Party can utilize server_callback_url or [status API command](https://doc.payneteasy.com/integration/api_v2_status.html.md). Pass https://doc.payneteasy.com if there is no need to redirect Receiver anywhere. Use either combination of redirect_fail_url and redirect_success_url or redirect_url, not both. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| credit_card_number | Customer’s credit card number. **Note: For the scenario of payment to a card inside the system, this card will be considered as a source, and all processing limits, lists and fraud scoring will be applied to it as a source card.** | `Necessity`: Conditional `Type`: Numeric `Length`: 20 |
| card_printed_name | Customer’s full name, as printed on the card. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire_month | Credit card expiration month. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| expire_year | Credit card expiration year. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| cvv2 | Receiver’s CVV2 code. CVV2 (Card Verification Value) is a three- or four-digit number AFTER the credit card number in the signature area of the card. | `Necessity`: Conditional `Type`: Numeric `Length`: 3-4 |
| account_number | Account Number. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| account_name | Bank account. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ewallet_type | Type of e-wallet. | `Necessity`: Conditional `Type`: String `Length`: 64 |
| ewallet_wallet | E-wallet ID. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| crypto_wallet_address | Address of crypto wallet. | `Necessity`: Conditional `Type`: String `Length`: 64 |
| bank_name | Bank Name. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_branch | Bank Branch Name. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_code | Bank code. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| bank_city | Bank city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| bank_address1 | Bank address. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_zip_code | Bank postal ZIP code. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_province | Bank province. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| bank_area | Bank area. | `Necessity`: Conditional `Type`: String `Length`: 255 |
| routing_number | Routing number used to identify specific bank branches in China. | `Necessity`: Conditional `Type`: String `Length`: 16 |
| legal_person_name | Name on the legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| legal_person_document_number | Number of legal document. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_first_name | Receiver first name, also can be sent as first_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_last_name | Receiver last name, also can be sent as last_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_middle_name | Receiver middle name, also can be sent as middle_name. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_birthday | Receiver birthday, also can be sent as birthday. | `Necessity`: Conditional `Type`: Numeric `Length`: 30 |
| receiver_country_code | Receiver country code, also can be sent as country. | `Necessity`: Conditional `Type`: String `Length`: 3 |
| receiver_state | Receiver state, should be provided for countries that have states (USA, Canada, Australia), also can be sent as state. | `Necessity`: Conditional `Type`: String `Length`: 4 |
| receiver_city | Receiver city, also can be sent as city. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_zip_code | Receiver zip code, also can be sent as zip_code. | `Necessity`: Conditional `Type`: Numeric `Length`: 32 |
| receiver_address1 | Receiver address, also can be sent as address1. | `Necessity`: Conditional `Type`: String `Length`: 256 |
| receiver_phone | Receiver phone, also can be sent as phone. | `Necessity`: Conditional `Type`: Numeric `Length`: 128 |
| receiver_email | Receiver E-mail, also can be sent as email. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_id | Receiver identity document identifier, also can be sent as identity_document_id. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| receiver_identity_document_number | Receiver identity document number, also can be sent as identity_document_number. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| merchant_data | Any additional information for this transaction which may be useful in Connecting Party’s external systems, e.g. VIP customer, TV promo campaign lead. Will be returned in Status response and Connecting Party Callback. | `Necessity`: Optional `Type`: String `Length`: 64k |
| bank_bic | BIC of the receiver’s bank. | `Necessity`: Optional `Type`: String `Length`: 128 |
| receiver_inn | Receiver’s INN. | `Necessity`: Optional `Type`: String `Length`: 128 |
| customer_level | Customer level in CMS system | `Necessity`: Optional `Type`: Varchar `Length`: 32 |
| customer_id | Customer ID in CMS system. Required if transaction goes via CMS (Payment Gateway mode) | `Necessity`: Optional `Type`: Int `Length`: 10 |
| merchant_customer_identifier | Merchant Customer ID in CMS system. Required if transaction goes via CMS (CRM mode) | `Necessity`: Optional `Type`: Varchar `Length`: 64 |
| card_recurring_payment_id | Payer’s tokenized cardholder’s data ID, referred as Recurring Payment ID (RPI). Send either card_recurring_payment_id or combination of credit_card_number, card_printed_name, expire_month and expire_year, not all. To create card_recurring_payment_id see [/api/v4/create-card-ref](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). **Note: For the scenario of payment to a card inside the system, this card will be considered as a source, and all processing limits, lists and fraud scoring will be applied to it as a source card.** | `Necessity`: Conditional `Type`: Long |
| recurring-payment-id | Recurring Payment ID can be sent instead of cardholder data. Customer Data can be updated via [/api/v4/update-recurring-payment/](https://doc.payneteasy.com/integration/api_v4_update-recurring-payment.html.md). Recurring Payment ID creation is initiated through HTTPS POST request by using [URLs](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) and the [parameters](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. | `Necessity`: Conditional `Type`: Long |

\* Ask Support Manager if Conditional fields are Required for integration.

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Payout Response Parameters | Description |
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/v4/payout/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="b5E31Tw6SVjauE29uOf2jOLnuUSXmVdE", oauth_signature="WrW79JHNUVwDRhCGWQYgaN6xmJXpQxy8XSNyCOL6b2Wyf7V5BWGMe2TZa1bjC9ZeO0Q3FcQxeGGHv0%2F7hsMAsJNQEET321VNsbDwao2Ep%2Bp7eoYiGYrVveSrSW1diCrBf3AJYJZM0PTJ67Sl8XyeTVBHT4kpC5qBu3xDQ3aFfKnmRTmn9fiVsYsYu3DQrsHM1K9uAoltGt3Muz0kCDZ3MWNGrNqtdpWuar8HRQD3kckcPjuN9D6VrSuQm9eLx27G%2FvkiP%2BZ44i8ghIUp61NWSrJ4Ky69JiZ%2FoaVVmUTEaanc%2F%2B%2BQT6jBwWy%2Bb%2FTLUrxtSakeNfcjn1JVwRf4aCX2fhyG5ozH%2BjiXF6eRb83WVqBUAwykSq35pLU3Vmua3pKMKAJK1ZRDZdjGrT50KJg5tBniC4JFzdQqjQf%2FhFnDYodfIK3S2qZo%2FD3Bmlya46iEcK6SAQdNBBQue3E5Qi8FEHYrY1o7K8wDyzT1QzqqHF%2BQdmXcElSGu9ge0Y655%2BbGtXhnsUWnKEO0NGqErvAwzm7yUg0e5QWHVf505aE7pr5K4z%2Fzj7AvkuD7R1savqam%2BnnuSfq1E%2BnnnN7mTcC0g18Sr38vdTshcGq99YW3xWKc%2FpuooZYdYa5A6u46o%2BREZSTCD2XexcV49%2F9eVn3xdoTXYq4NISJSY8U7ThKnr0g%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1677831012", oauth_version="1.0"
Content-Length: 150
Content-Type: application/x-www-form-urlencoded
Connection: close

account_name=1234
&account_number=1234
&amount=10.42
&client_orderid=1
&currency=USD
&routing_number=15
&server_callback_url=https%3A%2F%2Fhttpstat.us%2F200
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 03 Mar 2023 08:10:34 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002e2c322
&merchant-order-id=1
&paynet-order-id=6982864
&end-point-id=39915
```

#### Fail Response Example

```http
HTTP/1.1 403 Forbidden
Server: server
Date: Thu, 25 Aug 2022 06:50:16 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
  <title>403</title>

</head>

<body>
<p>Access is denied</p>
</body>
</html>
```

#### Test Scenario

Different Payout transaction statuses can be received on sandbox depending on the account_number value passed in Payout request.

Testing account_number values:

> * account_number = 1234567890 to get APPROVED
> * account_number = 0987654321 to get DECLINED
> * account_number = 1987654321 to get PROCESSOR_INTERNAL_ERROR

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/payout/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/process-recurring-payment

#### Introduction

If request is accepted with no errors, the Payment Gateway finds the recurring payment profile by the provided recurring-payment-id and initiates a new recurring transaction using the payment data saved in this profile.
 
Process recurring payment is initiated through HTTPS POST request by using [URLs](#api-v4-process-recurring-payment-request-url) and the [parameters](#api-v4-process-recurring-payment-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------------|-------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/process-recurring-payment/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/process-recurring-payment/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client-orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| recurring-payment-id | Recurring ID assigned to the order by QA. | `Necessity`: Required `Type`: String `Length`: 10 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. Example: process-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| status | If request is accepted, this parameter has processing value. This is not a transaction status. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |

#### Request Example

```http
POST /paynet/api/v4/process-recurring-payment/ HTTP/1.1
User-Agent: curl/8.4.0
Accept: */*
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant", oauth_nonce="XGsxKTfd4uiaQKOSyXkHQwKxFqLCEKRz", oauth_signature="KX7KEjFUEJo8rLJ2PvusGDlu5cxqMm%2BU%2Bn%2F1KxH18QUeZ57QghfnXyiXKCxwAr76uxMk9X10QL8YI4kuEHVmxThIomtIZML3yRLESneHNqZzlwXvTSG5o%2B7DTSdAeNGZ40PIbF4XAUzwp%2FQbpYGWBS4Yk36%2BPQbziJlsFa21gRo7e03fizxPEIYi1algEqOT5uu%2F07Yci6NsSyGGMGo4vyDhqPMLuDcaTeO%2Fzr51RfRa4jh2bT4tUriZLVrjYP0AJeHGlZdosTkqEyVAz5Q5yD67xmjUGlW4luezOWdR70wrfQ8JZ7QuXzueAb9TqyZfi%2BvCD4MrhXG299ujWUUtZ%2F8qi09p%2F7GmBiFSud7wgMjPGOC%2BijBEFIpsfiBFzd6%2FX7MBLAdTpHXrExT2C71dJysde31isAMVuIIuvXogY7YE0ZttWY1oYqcWDNSWXsUx5pQTjbBf1vyJB3CqtAFVFi6LwckqsYTAXkxfp%2B2IgFFhadEvf35XzFPv%2FEjsTqRLJuPYBa85mK9vaY7WJRtX89TjSdEPulFnz1EEFg5KHe5WxVp9GFw2XqLneqBu%2FwGAGg3NXRumBMHK3E%2Bh96cVdU5b3AkqVjS2Q36jpQtAhUIIGYyT02n4W9avhw2cHCJzErqGjALHJjkFQD1bhDRKyTm1Fqeh%2BplDaPwDKjy5EHY%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1721316898", oauth_version="1.0"
Content-Length: 407
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

recurring-payment-id=1492124
&amount=10
&client-orderid=1575634981130
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 18 Jul 2024 15:35:46 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 110

type=process-recurring-payment-response
&serial-number=00000000-0000-0000-0000-000002f36d8d
&status=processing
```

#### Fail Response Example

```http
HTTP/1.1 500
Server: server
Date: Thu, 18 Jul 2024 15:39:05 GMT
Content-Length: 61
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [b2a06c5a-c770-4c01-b32c-e4fcb1da4cd6]
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/process-recurring-payment/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/process-recurring-payments

#### Introduction

If request is accepted with no errors, the Payment Gateway finds the recurring payment profiles for each provided recurring-payment-id and initiates new recurring transactions using the payment data saved in each profile.
 
Process recurring payment Multiple is initiated through HTTPS POST request by using [URLs](#api-v4-process-recurring-payments-request-url) and the [parameters](#api-v4-process-recurring-payments-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-----------------------------------------------------------------------------------|--------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/process-recurring-payments/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/process-recurring-payments/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Below is a description of each parameter that can be included in the CSV and added to payload parameter which will be used in the request.
 

| CSV Parameter Name | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| client-orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| recurring-payment-id | Recurring ID assigned to the order by QA. | `Necessity`: Required `Type`: String `Length`: 10 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. Example: process-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. Multiple error codes may be received: 200, 403, and 500. For the 500 error code, an additional error ID will be returned. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant |

#### Request Example

**Step 1.** Create a CSV with the provided structure:
 
```http
"client-orderid";"recurring-payment-id";"amount"
```

**Step 2.** Encode CSV to base64 with the following command:
 
```bash
base64 process-recurring-payments-example.csv
```

**Step 3**. Assign the base64 encoded value to payload parameter and send the request:
 
```http
POST /paynet/api/v4/process-recurring-payments/ HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/8.4.0
Accept: */*
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant",oauth_signature_method="RSA-SHA256",oauth_timestamp="1727177782",oauth_nonce="Js4dwXkF8eI",oauth_version="1.0",oauth_signature="EGLiLoJJsZzZ4LgTdexkExuNCeyJEkSYuQwsrLMTvucJiIoG2rXL%2FaIkwnXwY6ncXS%2BopSYszmvAE1KnR316YxfyPzvgwO7LkrCE9r80yEfYuGOjwdB7fqvCyYtPqylS7MJ0%2BJM1EIowuWkiwURLqU3mG4J00t1Kl7CRrsjT9nwKoj8mRrljb1St3rAh8bJ7SsdKKQwir1Va6t0cuVMxjsUHJqCtztoCXAPj%2BRz4UKrjbQnwNvJ1MfOnTyeRXTAJgGg7XwctumcG5W2vfuKICwEUQ9S95jxXIci%2FmHuA8gkV7DmfolT1CnxDYzhJwvspvg9BP%2FFVxOGjUTEKDwNhCX5BB3B6EUkyEFI79V8tAtUdUy%2FzRmChPA%2FYvyBky8egkVXoKgwoUHiTQ5ITEhbzCTLjuVm9J%2FEwqVHQkwPbn6T5aTcvQBoMkDtZ70qm7J73wPKuN%2B7S%2Fi0SBc6gwGyu6G%2FfXYu%2BvDY8Ihtd6HRUC59sUYQ6D3tVbh8CE4W9tF1UiXCAoPehdBga%2BR6WUq%2FnD%2FRFrBDZ2Y%2Bz%2FMGhjQHBNZu%2B5z4JjNn7QusHpO1ZwvrI1kSlK79toVOiwVX%2FcP4H5M20s5EPjvSrcc2tnqQSUUOLFGyRFObQgs7kmBxUjEMXbVh9QXlIBdSvy4S8PkFnqYjVLh2aNgTpw%2BgB8RrZ1MY%3D"
Content-Length: 888
Connection: keep-alive

payload=cmVjdXJyaW5nLXBheW1lbnQtaWQ7Y2xpZW50LW9yZGVyaWQ7cGF5bWVudC1kZXNjcmlwdGlvbjtmaXJzdC1uYW1lO2xhc3QtbmFtZTthZGRyZXNzMTtjaXR5O3ppcC1jb2RlO2NvdW50cnk7c3RhdGU7cGhvbmU7ZW1haWw7Y3VzdG9tZXItaXA7YW1vdW50O2N1cnJlbmN5O3B1cnBvc2U7bm90aWZ5LXVybDtzc247YmlydGhkYXkNCjE0OTIyODY7MTIzNDU2Nzg5MDtPdXIgZ29vZHM7Sm9objtTbWl0aDsxMjM0IFBlYWNlIHN0cmVldDtDaGljYWdvOzEyMzQ1NjtVUztJTDsxMjM0NTY3ODtqb2huLnNtaXRoQGV4YW1wbGUuY29tOzEuMi4zLjc7MTA7VVNEO05vIHB1cnBvc2UgYXQgYWxsO2h0dHA6Ly9leGFtcGxlLmNvbS9wcm9jZXNzLW1lOzEyMzQ7MDIuMDEuMTk4MA0K
```

#### Success Response Example

> **Note:** The successful response has empty body and HTTP code 200.

```http
HTTP/1.1 200
Server: server
Date: Tue, 24 Sep 2024 09:47:01 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
```

#### Fail Response Example

> **Note:** The unsuccessful response has empty body and HTTP code 403.

```http
HTTP/1.1 403
Server: server
Date: Wed, 25 Sep 2024 08:46:12 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
```

### /api/v4/status

#### Introduction

To make an order status request one have to send an HTTPS POST request to the [URLs](#status-request-v4-url) and the [parameters](https://doc.payneteasy.com/integration/api_v2_status.html.md) specified below. Use [RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|--------------------------------------------------------------------------|-----------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/status/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/status/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/status/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/status/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

| Parameter Name | Description | Necessity |
|------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| login | Connecting Party login name. | Mandatory |
| client_orderid | Unique order identifier assigned by Connecting Party. | Mandatory |
| orderid | Order id assigned to the order by Payneteasy. | Conditional |
| by-request-sn | Serial number assigned to the specific request by Payneteasy. If this field exist in status request, status response return for this specific request. Include this parameter to get the status request with the particular transaction stage (can be used in specific cases). To get the latest transaction status, don’t include this parameter in status request. | Optional |
 
In most common cases, the best option is to include both client_orderid and orderid parameters to status request. Order status can be requested with only client_orderid if it’s unique to Connecting Party and orderid is not received. If orderid is not received in response, but this response contains an error, see the received error message to get the information why transaction was not created in the system.
 

#### Response Parameters

The same API command for status request is used in multiple Use-Cases, therefore some of the mentioned response parameters might not be present for specific case. Below is the full list of possible parameters.
 

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

\* - these parameters are not defined by default. Please contact tech support to include these fields in callback.
 

| Status Response Parameter | Description |
|-------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be status-response. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| amount | Actual transaction amount. This value can be changed during the transaction flow. |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar EUR for European Euro. |
| paynet-order-id | Order id assigned to the order by gate.payneteasy.eu. |
| merchant-order-id | Connecting Party order id. |
| phone | Payer’s full international phone number, including country code. |
| html | HTML code of 3DS authorization form, encoded in application/x-www-form-urlencoded MIME format. Connecting Party must decode this parameter before showing the form to the Payer. gate.payneteasy.eu System returns the following response parameters when it gets 3DS authorization form from the Issuer Bank. It contains auth form HTML code which must be passed through without any changes to the client’s browser. This parameter exists and has value only when the redirection HTML is already available. For non-3DS this never happens. For 3DS HTML has value after some short time after the processing has been started. |
| redirect-to | For 3DS authorization Connecting Party can redirect the Payer to URL provided in this parameter instead of rendering the page provided in html parameter. The redirect-to parameter is returned only if the html parameter is returned. Connecting Party should use GET HTTP method to redirect. This parameter must be used to work with 3DS 2.0. |
| serial-number | Unique number assigned by gate.payneteasy.eu server to particular request from the Connecting Party. |
| last-four-digits | Last four digits of Payer bank card number. |
| dest-last-four-digits | Last four digits of customer credit card number. Relevant only for transfer transactions. |
| bin | Bank BIN of Payer bank card number. |
| card-type | Type of Payer bank card (VISA, MASTERCARD, etc). |
| gate-partial-reversal | Processing gate support partial reversal (enabled or disabled). |
| gate-partial-capture | Processing gate support partial capture (enabled or disabled). |
| transaction-type | Transaction type (sale, reversal, capture, preauth). |
| processor-rrn | Bank Receiver Registration Number. |
| processor-tx-id | Acquirer transaction identifier. |
| receipt-id | Electronic link to receipt https://gate.payneteasy.eu/paynet/view-receipt/ENDPOINTID/receipt-id/. |
| name | Payer’s name. |
| card-ref-id | Card reference ID used in subsequent recurrent payments. Relevant only if card-ref-id was created for initial transaction. |
| cardholder-name | Cardholder’s name. |
| card-exp-month | Bank card expiration month. |
| card-exp-year | Bank card expiration year. |
| card-hash-id | Unique card identifier to use for loyalty programs or fraud checks. |
| card-country-alpha-three-code | Three letter country code of source card issuer. See [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| destination-card-country-alpha-three-code | Three letter country code of destination card issuer. See [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| dest-bin | Bank BIN of customer credit card number. |
| dest-card-type | Type of customer credit card (VISA, MASTERCARD, etc). |
| dest-bank-name | Bank name by customer card BIN. |
| destination-hash-id | Unique card identifier to use for loyalty programs or fraud checks. Relevant only for transfer transactions. |
| destination-card-hash-id | Unique card identifier to use for loyalty programs or fraud checks. |
| first-name | Payer’s first name. |
| last-name | Payer’s last name. |
| email | Payer’s e-mail. |
| country \* | Payer’s country (two-letter country code). Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. |
| state \* | Payer’s state . Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Mandatory for USA, Canada and Australia. |
| city \* | Payer’s city. |
| zip_code \* | Payer’s ZIP code. |
| address1 \* | Payer’s address line 1. |
| purpose | Destination to where the payment goes. It is useful for Connecting Party who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. |
| bank-name | Bank name by Payer card BIN. |
| terminal-id | Acquirer terminal identifier to show in receipt. |
| paynet-processing-date | Acquirer transaction processing date. |
| approval-code | Bank approval code. |
| order-stage | The current stage of the transaction processing. See [Order Stage](https://doc.payneteasy.com/integration/reference/order_stage.html.md) for details. |
| total-reversal-amount | Total amount of processed reversals. Relevant only for reversal transactions. |
| reversal-amount | The amount of the last processed reversal. Relevant only for reversal transactions. |
| auth-response-code | Response code used in Iso8583 protocol. Only returned in specific cases. |
| acquirer-processing-date | Acquirer transaction processing date. |
| processor-auth-credit-code | Approval credit code. Only returned in specific cases. |
| processor-credit-rrn | Retrieval Reference Number for credit transaction. |
| processor-credit-arn | Acquirer card reference number for credit transaction. |
| processor-debit-arn | Acquirer card reference number for debit transaction. |
| loyalty-balance | The current bonuses balance of the loyalty program for current operation. if available. |
| loyalty-message | The message from the loyalty program. if available. |
| loyalty-bonus | The bonus value of the loyalty program for current operation if available. |
| loyalty-program | The name of the loyalty program for current operation if available. |
| descriptor | Bank identifier of the payment recipient. |
| original-gate-descriptor | Descriptor, which is set on gate level in the system. |
| error-message | If status in declined, error, filtered this parameter contains the reason for decline. |
| error-code | The error code is case status in declined, error, filtered. |
| by-request-sn | Serial number assigned to the specific request by gate.payneteasy.eu. If this field exist in status request, status response return for this specific request. |
| verified-3d-status | See [3D Secure Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| verified-rsc-status | Returned if Random Sum Check was performed. See [Alternative cardholder authentication](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) |
| eci | Electronic Commerce Indicator (Visa). |
| ips-src-payment-product-code | Code for card set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-product-name | Decrypted code for card set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-type-code | Type of card code set by multinational financial service (Visa/Mastercard). |
| ips-src-payment-type-name | Decrypted code for type of card set by multinational financial service (Visa/Mastercard). |
| merchantdata | If provided in initial request, merchant_data parameter and its value will be included in status response. |
| initial-amount | Amount, set in initiating transaction, without any fees or commissions. This value can’t change during the transaction flow. |
| seller-commission | Total commission for processed transaction. This is optional parameter. Please contact your manager in Payneteasy, if you would like to receive it. |
| acquirer-commission | Acquirer commission for processed transaction. This is optional parameter. Please contact your manager in Payneteasy, if you would like to receive it. |
| motivational-message | This is an optional message which contains extended information about the reason for the declined transaction. |
| transaction-date | Date of final status assignment for transaction. |
| orig-amount | Contains the original request amount if it was converted on auxiliary endpoint in Parallel form integration. Relevant only for Payment Cashier transactions. |
| orig-currency | Contains the original request currency if it was converted on auxiliary endpoint in Parallel form integration. Relevant only for Payment Cashier transactions. |

#### Pa Req Form Status Response Parameters

| Name | Description |
|------------------------|-----------------------------------------------------------------|
| tds-pareq-form-pareq | ACS 3DS Pa Req data, which received by the Connecting Party. |
| tds-pareq-form-acs-url | ACS URL to redirect the Payer to 3DS 1.0.2 Authentication Flow. |

#### CReq Form Status Response Parameters

| Name | Description |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| tds-creq-form-creq | A CReq message initiates Cardholder interaction in a Challenge Flow and is used to carry authentication data from the Cardholder. It is formed by the 3DS Server and is posted through the Cardholder’s browser by Connecting Party to the ACS URL. |
| tds-creq-form-acs-url | ACS URL to redirect the Payer for Challenge Flow. |

#### Method Url Frame Status Response Parameters

| Name | Description |
|------------------------------------------|--------------------------------------------------------------------------------------------------------|
| tds-method-url-frame-3ds-server-trans-id | Universally unique transaction identifier assigned by the 3DS Server to identify a single transaction. |
| tds-method-url-frame-3ds-method-url | 3DS Method URL used in iframe form which is provided to Payer browser by Connecting Party. |

Rules to form the HTML form.

threeDSMethod Data (threeDSMethod NotificationURL + threeDSServer TransID).
 

#### Request Example

```http
POST /paynet/api/v4/status/46750 HTTP/1.1
User-Agent: curl/7.88.1
Accept: */*
Authorization: OAuth oauth_consumer_key="Test_Merchant", oauth_nonce="BKOz6eHOs6sDJlLPAJhbDHAaXCy9xxNv", oauth_signature="eQXkV%2BJdiqJlyRqNaEzIKmYa3FZzUjdcMR6lXSfRn9tOYKUNPxI3UKU%2F%2FGsPpofXL%2B2RBjGh3Gqv%2BZBoKaVKOgNKwNNwpA4IOaskV71uuMbZCp0gPEbS%2BVaWLD8vzqpcgZ%2Bd5DRNMfimyXkWVWbsMUYj8N%2BSpXl4YnGIo0nXz9Q0Ppxetie3EG9NrN7CNu7NdovVjmstfYqpDRv9OhLo4tSQTD9C6bWvW2kmEvZsb2d1KANsGUW6rXyjkIoPxJ2XigIXBOUfwSWj9cV7SsZ%2FNk%2FVjNWgav2uw9J9I%2FiTqLLcKZ1pTWj1WOMwXhfoMCP10XOAOe72CQHX0DJL%2BFt01jmOXLvLdEkUZTFzsC6DGfHSDdcsjXquc9gxFKVr3d8e15by3566UI4pXKef%2Fe%2B3Ytvlrj7IUhIcNyA%2BVXp%2FwivxgwYu2xpQJMs6wlvw6Lz3N2wcFRqLs5ZEbdZ1%2F29pox8XW0ae8yZ2z2PClPzmJIoDcOr0GEtwyz5ByyeW0m33XA67UbPN6rwbdlVL2gwMqWwkn7KDYp7%2BifP%2B2BdbyXnw2LeJcuYDYAIDHa%2Bi0P09ZVToBpeLOx%2FobSF2y%2FsheVgo0O%2FRWtUEEXONvd0n7hEdnJ7mMYNivNitbfQ4SryQ2o8CdUDk9RgEaR7pn7ybTi4rQEhDqWF8sFMtaKhFn9o%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1734327207", oauth_version="1.0"
Content-Length: 58
Content-Type: application/x-www-form-urlencoded
Connection: close

client_orderid=1&login=Test_Merchant&order_id=7364742
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 16 Dec 2024 05:38:33 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 1469

type=status-response
&serial-number=00000000-0000-0000-0000-000002f38234
&merchant-order-id=123456
&processor-tx-id=PNTEST-7364748
&paynet-order-id=7364748
&status=approved
&amount=10.42
&currency=USD
&descriptor=Test
&original-gate-descriptor=Test
&transaction-type=transfer
&receipt-id=2f885ae0-5220-3549-8eb5-622f4201f882
&name=John+Doe
&cardholder-name=John+Doe
&card-exp-month=12
&card-exp-year=2099
&processor-rrn=0435171505391
&approval-code=466875
&order-stage=transfer_approved
&last-four-digits=5721
&bin=421070
&card-type=VISA
&bank-name=DEMIRBANK+OJSC
&dest-bank-name=JPMORGAN+CHASE+BANK+N.A.
&dest-bin=423261
&dest-last-four-digits=1636
&dest-card-type=VISA
&auth-response-code=00
&paynet-processing-date=2024-12-16+08%3A37%3A25+MSK
&acquirer-processing-date=2024-12-16+08%3A37%3A25+MSK
&processor-auth-credit-code=311830
&card-hash-id=2511341
&destination-card-hash-id=2511340
&card-country-alpha-three-code=AZE
&destination-card-country-alpha-three-code=USA
&verified-3d-status=NOT_AUTHENTICATED
&processor-credit-rrn=0435147814453
&processor-credit-arn=899834666
&processor-debit-arn=668539305
&ips-src-payment-product-code=UNK
&ips-src-payment-product-name=Unknown
&ips-src-payment-type-code=Credit
&ips-src-payment-type-name=VISA+Credit
&ips-dst-payment-product-code=UNK
&ips-dst-payment-product-name=Unknown
&ips-dst-payment-type-code=Prepaid
&ips-dst-payment-type-name=VISA+Prepaid
&initial-amount=10.42
&transaction-date=2024-12-16+08%3A37%3A34+MSK
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Mon, 16 Dec 2024 05:33:57 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 164

type=status-response
&serial-number=00000000-0000-0000-0000-000002f38231
&merchant-order-id=1
&status=error
&error-message=AMBIGUOUS_CLIENT_ORDER_ID
&error-code=124
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/status/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/transfer-form

#### Introduction

Transfer is a type of complex transaction that allows to move funds between bank cards (Primary Account Number - PAN), card tokens (Recurring Payment ID - RPI) and Connecting Party bank account (deposits).
 
Transfer Form integration is relevant for Connecting Party who are not able to accept Connecting Party order ID. card details (Connecting Party’s website must complete PCI DSS certification). Using Transfer Form integration Connecting Party is released of accepting payment details. In this case the accepting and processing of payment details is carried out on the Payneteasy side (if PAN is not sent). This type of integration also allows the Sender (for transfers between cards) or Receiver (for deposit to card) to submit their PAN on Payneteasy side.
 
Transfer is initiated through HTTPS POST request to the [URL](#transfer-form-api-urls) with the [required parameters](#api-v4-transfer-form-request-parameters-usage) depending on a certain transfer Use-Case (see below). Use [RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 
Transfer Form Use-Cases diagram:
 
```plantuml
hide members
hide circle

circle " " as c2
package From <<Frame>> {
class "Form" as f1a
class "Card number\n(Pan)" as pan1a
class "Reccuring Payment ID\n(RPI)" as rpi1a
class "Connecting Party Account\n(Deposit to card)" as dca

}
package To <<Frame>> {
class "Card number\n(Pan)" as pan2
class "Reccuring Payment ID\n(RPI)" as rpi2
class "Form" as f2

}

f1a --|> pan2
f1a --|> rpi2
f1a -- c2
pan1a -- c2
rpi1a -- c2
dca -- c2
dca -[hidden]> f2
c2 --|> f2
```

| Form to PAN | Transfer from Form to PAN occurs when transferring funds from payment details indicated in form to bank card for which its number is indicated. |
|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Form to RPI | Transfer from Form to RPI occurs when funds are transferred from payment details indicated in form to bank card for which its recurring payment id is indicated. |
| PAN to Form | Transfer from RPI to Form occurs when funds are transferred from one bank card for which its number is indicated to payment details indicated in form. |
| RPI to Form | Transfer from RPI to Form occurs when funds are transferred from one bank card for which its recurring payment id is indicated to payment details indicated in form. |
| Form to Form | Transfer from Form to Form occurs when funds are transferred from payment details indicated in form to another payment details indicated in form. |
| Deposit to Form | Transfer from deposit to Form occurs when funds are transferred from Connecting Party account to payment details indicated in form. |

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer-form/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/transfer-form/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer-form/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/transfer-form/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Form to PAN

| Parameter | Description | Value |
|-------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| destination-card-no, alias destination | Receiver\`s card PAN. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receivers’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Form to RPI

| Parameter | Description | Value |
|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| destination_card_recurring_payment_id | Receiver\`s recurring payment ID. To create destination_card_recurring_payment_id please see Card Reference ID Creation. | `Necessity`: Required `Type`: Long |
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receivers’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], control characters [=&], 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

PAN to Form

| Parameter | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| credit_card_number | Sender\`s credit card number. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| expire_month | Sender credit card’s month of expiration. | `Necessity`: Required `Type`: String `Length`: 2 |
| expire_year | Sender credit card’s year of expiration. | `Necessity`: Required `Type`: String `Length`: 2-4 |
| card_printed_name | Sender\`s card printed name. | `Necessity`: Required `Type`: String `Length`: 128 |
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receivers’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], control characters [=&], 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

RPI to Form

| Parameter | Description | Value |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| card_recurring_payment_id | Sender\`s recurring payment ID. To create card_recurring_payment_id please see Card Reference ID Creation. | `Necessity`: Required `Type`: Long |
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receivers’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], control characters [=&], 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Form to Form

| Parameter | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receiver’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], control characters [=&], 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Deposit to Form

| Parameter | Description | Value |
|----------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| deposit2card | Marker of deposit to card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: True `Type`: Boolean |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101. | `Necessity`: Required `Type`: String `Length`: 45 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| first_name | Sender or Receiver’s first name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| last_name | Sender or Receiver’s last name. | `Necessity`: Optional `Type`: String `Length`: 50 |
| ssn | Last four digits of the Sender or Receiver’s social security number. | `Necessity`: Optional `Type`: Numeric `Length`: 4 |
| birthday | Sender or Receiver’s birthday. | `Necessity`: Optional `Type`: Numeric `Length`: 8 |
| address1 | Sender or Receiver’s address. (Please note that in some cases it is not possible to send address length more than 50 characters. Please contact your manager for more details.) | `Necessity`: Optional `Type`: String `Length`: 256 |
| city | Sender or Receiver’s city. | `Necessity`: Optional `Type`: String `Length`: 50 |
| state | Sender or Receiver’s state (two-letter state code). Please see Mandatory State Codes for a list of valid state codes. Required for USA, Canada and Australia. | `Necessity`: Optional `Type`: String `Length`: 2 |
| zip_code | Sender or Receiver\`s zip code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| country | Sender or Receiver’s country (two letter abbreviation). | `Necessity`: Optional `Type`: String `Length`: 2 |
| phone | Sender or Receiver’s full international phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| cell_phone | Sender or Receiver’s full international cell phone number, including country suffix. | `Necessity`: Optional `Type`: String `Length`: 15 |
| purpose | Destination to where the payment goes. It is useful for the merchants who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999;mail@example.com etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| email | Sender or Receiver’s email address. | `Necessity`: Optional `Type`: String `Length`: 50 |
| site_url | URL the original transfer is made from. | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved or declined. Optional for direct integration (non-form) deposit2card. This parameter must be used if there is neither redirect_success_url nor redirect_fail_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_success_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is approved. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| redirect_fail_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected only in case if the transaction is declined or filtered. This parameter should not be used to retrieve results from Payneteasy gateway, because all parameters go through client’s browser and can be lost during transmission. To deliver the correct payment result to the backend server_callback_url must be used instead. gate.payneteasy.eu should be passed if non-3DS schema for transactions processing is used and there is no need to redirect Sender or Receiver anywhere. This parameter must be used if there is no redirect_url. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| preferred_language | Sender or Receiver’s two-letter language code for multi-language transfer forms. | `Necessity`: Optional `Type`: String `Length`: 2 |
| merchant_form_data | Parameters sent in merchant_form_data API parameter are parsed into macros with the same name, the parameter is url-encoded, example testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters [a-zA-Z0-9], parameter value characters [a-zA-Z0-9], control characters [=&], 2MB max size. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. | `Necessity`: Optional `Type`: String `Length`: 128 |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

#### Additional Parameters

##### Sender Customer Data

Parameters below can be required for specific integrations. For more information, please contact Support manager.

| Parameter Name | Description | Value |
|-------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------|
| sender_first_name | Sender’s first name. | `Type`: String `Length`: 128 |
| sender_last_name | Sender’s last name. | `Type`: String `Length`: 128 |
| sender_middle_name | Sender’s middle name/patronym. | `Type`: String `Length`: 128 |
| sender_ssn | Last four digits of the Sender’s social security number. | `Type`: String `Length`: 11 |
| sender_birth_place | Sender\`s birth place. | `Type`: String `Length`: 128 |
| sender_birthday | Sender’s birthday. | `Type`: String `Length`: 30 |
| sender_address1 | Sender’s address. | `Type`: String `Length`: 256 |
| sender_city | Sender’s city. | `Type`: String `Length`: 128 |
| sender_state | Sender’s US states (two letter abbreviation). Not applicable outside the US. | `Type`: String `Length`: 4 |
| sender_zip_code | Sender\`s zip code. | `Type`: String `Length`: 32 |
| sender_citizenship | Sender\`s citizenship. | `Type`: String `Length`: 128 |
| sender_country_code | Sender’s country (two letter abbreviation). | `Type`: String `Length`: 2 |
| sender_phone | Sender’s full international phone number, including country suffix. | `Type`: String `Length`: 128 |
| sender_cell_phone | Sender’s full international cell phone number, including country suffix. | `Type`: String `Length`: 128 |
| sender_email | Sender’s email address. | `Type`: String `Length`: 128 |
| sender_resident | Is sender a resident? | `Type`: Boolean |
| sender_identity_document_id | Sender\`s identity document name. | `Type`: String `Length`: 128 |
| sender_identity_document_series | Sender\`s identity document series. | `Type`: String `Length`: 12 |
| sender_identity_document_number | Sender\`s identity document number. | `Type`: String `Length`: 16 |
| sender_identity_document_issuer_name | Sender\`s identity document issuer. | `Type`: String `Length`: 128 |
| sender_identity_document_issuer_department_code | Sender\`s identity document issuer department code. | `Type`: String `Length`: 32 |
| sender_identity_document_issue_date | Sender\`s identity document issue date. | `Type`: Date |

##### Receiver Customer Data

Parameters below can be required for specific integrations. For more information, please contact Support manager.

| Parameter Name | Description | Value |
|---------------------------------------------------|-----------------------------------------------------------------------|------------------------------------------------------|
| receiver_first_name | Receiver’s first name. | `Type`: String `Length`: 128 |
| receiver_last_name | Receiver’s last name. | `Type`: String `Length`: 128 |
| receiver_middle_name | Receiver’s middle name/patronym. | `Type`: String `Length`: 128 |
| receiver_birth_place | Receiver\`s birth place. | `Type`: String `Length`: 128 |
| receiver_birthday | Receiver’s birthday. | `Type`: String `Length`: 128 |
| receiver_address1 | Receiver’s address. | `Type`: String `Length`: 256 |
| receiver_city | Receiver’s city. | `Type`: String `Length`: 128 |
| receiver_state | Receiver’s state. | `Type`: String `Length`: 2-4 |
| receiver_zip_code | Receiver\`s zip code. | `Type`: String `Length`: 32 |
| receiver_region | Receiver\`s region. | `Type`: String `Length`: 30 |
| receiver_area | Receiver\`s area. | `Type`: String `Length`: 50 |
| receiver_citizenship | Receiver\`s citizenship. | `Type`: String `Length`: 128 |
| receiver_country_code | Receiver\`s country (two letter abbreviation). | `Type`: String `Length`: 2 |
| receiver_phone | Receiver’s full international phone number, including country suffix. | `Type`: String `Length`: 128 |
| receiver_email | Receiver’s email address. | `Type`: String `Length`: 128 |
| receiver_resident | Is receiver a resident? | `Type`: Boolean |
| receiver_identity_document_id | Receiver\`s identity document name. | `Type`: String `Length`: 128 |
| receiver_identity_document_series | Receiver\`s identity document series. | `Type`: String `Length`: 12 |
| receiver_identity_document_number | Receiver\`s identity document number. | `Type`: String `Length`: 16 |
| receiver_identity_document_issuer_name | Receiver\`s identity document issuer. | `Type`: String `Length`: 128 |
| receiver_identity_document_issuer_department_code | Receiver\`s identity document issuer department code. | `Type`: String `Length`: 32 |
| receiver_identity_document_issue_date | Receiver\`s identity document issue date. | `Type`: Date |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter | Description. |
|-------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, ex:error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order ID. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| redirect-url | The URL to the page where the Connecting Party should redirect the client’s browser. Connecting Party should send HTTP 302 redirect, see General Transfer Form Process Flow. |

#### Request & Response Examples

##### Transfer from Form to PAN

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="eZCXwEp9fO17vGFwPUDStKjOKIP9u0nu", oauth_signature="2qrf7DY0fiy88doBrIGafZBqLLX12ePYWDGLqNxwBfU9T3RzwSYtEj92EPuiJulnZxbPY6av4F2jT1JS02D4KqPAtadsEYb8AabBoSvXPK13FrIXKQ38hrcapmXwz%2Fbh0JJBnN3aMvKJ%2FnsvRChY%2FFpRhdudfdBxZLKpAXYfJQgk42%2FB9pu%2FsBSRWJwTnVZxfavHYMWmrY2rvg2x1nedSJq6O%2Fxffz9OU3CvHOlK%2FGfdI4WFvpHIXpw1Mlz%2F6AnQRdMmYHnoDsFu79GI57NeoBRsZazJBYh%2FE%2FFcS9sHU5BF0yvLQYz%2FCXtb7lDbKeDJTHDDWakyyZPQcOQReIMHpNwNr9mjC%2FucIJitFEldsWWGaOnTc2Tqtrdjzzwukm%2BP7Bi5siJ5Pl%2BxWqOMAEFPnCXfThBKIJrxQXbBwR4YfPaBb70nePybCH8JCX0vakoaH%2BwFJfR0WNgOBfYxQfUYNcEXDmrk8hLbwz%2FXJ6bfanFaE8N3OwijJmlzY%2B4ZrEqBjnklQcBnNuvuxKSb6dKtnRo5UVXEszEiCxEvWQifggohkU1CTHZFpA2qmrxjIcgJoDOhQPV6Lk92LiDtVSE2drxZ%2Bjui69ZzGlnKlM0lVCnFfdahrhtMM9GYNN%2B24YaKd5UkCMIMru%2BfOfvqwrJu00%2FIms8VXwsm9aP8pP4Lr3I%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670421183", oauth_version="1.0"
Content-Length: 303
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&client_orderid=34T43R77N
&currency=USD
&deposit2card=false
&destination-card-no=4268736646656312
&destination_card_printed_name=Test%20Test
&destination_expire_month=12
&destination_expire_year=2023
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Wed, 07 Dec 2022 13:56:03 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddbfa2
&merchant-order-id=34T43R77N
&paynet-order-id=6863810
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A577953626976766D4B494A66796F55434370393032673D
```

**Fail Response Example**

```html
HTTP/1.1 403
Server: server
Date: Mon, 12 Dec 2022 08:25:15 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>403</title>
    
</head>
<body>
    <p>Access is denied</p>
</body>
</html>
```

##### Transfer from Form to RPI

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="yQFnx1Zerg4pH28VmLQL3HWc7dQJlAqg", oauth_signature="G2ZRjHOxzhsQ5xIurkM7Bo7REnoBfG3HIDDzwG9XfFGZdFC0815%2FPVS4ESdLPYVEr7iT2K3LtlO2mhMzmIWuRV3YTVKKCbfbuJkPk1OwJOx66ZaX4q0DI5Zej%2FadXiKuJ%2FLe%2BLL8Tp%2Ftzrylk6fiTAoX2AT471hp02xezERVwdEwkhoWB1mqwYE4VxOL8wDk0W0oqR%2Bk1XgWXPcj3E8WV3kEVFwxYwgi6daQyimqReEc5q8fqbUl7sANmIozrSRWqjG2K%2FBLs0W2UFLMcvWdHi2ON%2B%2BnTzaLCExB2991ozSE2jPp4eahkd69Zz%2BEwLENVIn8KDwvA5j25XaGgbqLKK%2BBt5CshObkvZZZ%2FuWqujp%2FzbOBGMuucuwyXe4yW8Ter1YC%2F9zoR%2BMwIcKBd5gaV4mOxQCZ5pe9GMD2805BlM2XDtcB9UT%2FeMs3MR3WIXN51EVCn%2BcazxwEI4LmZ5966aaUGu4GF41JWRQAZBchx4F%2Bd%2BRadwCceBJJSiQg82hwRk4QYnyDEx%2BWqcwErVZGCH8yJhph1Etn3e0G8z0PLBlG2hqTqGPFYivzyFHI1LNW8jl7%2BKJq2HZgXjtcU8Ji%2BVw2JVr86nnM4nPbpIRl7qr%2BSYUpXjWw%2B3e%2F6GtOL%2BOWzVFMo5jKf%2FfyJSdOgbyco1sBHplZRZ8Gsts8UGiIuQ8%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670847388", oauth_version="1.0"
Content-Length: 213
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&client_orderid=34T43R77N
&currency=USD
&deposit2card=false
&destination_card_recurring_payment_id=1491854
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 12:17:14 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddc2d7
&merchant-order-id=34T43R77N
&paynet-order-id=6863948
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A66354B455A714F6F32684D61414E78767241354872343D
```

**Fail Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 12:08:14 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 132

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddc2b8
&error-message=Recurring+payment+not+found
&error-code=122
```

##### Transfer from PAN to Form

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="BpGsiUR8CbIjGAD1Qxu8MTtGHnlIvzcF", oauth_signature="ozovWc0wjugTlGfrS8TeSxqQtnSEQ7UrGh7z6B5px5BoKgTWF44Ej6VCAxCWMl%2B1Qxg5iZ5ExOqTWZ2GTx70ly%2B%2BgHkSmz3t02PEr9XJsj2%2FOm4XFoF0LnbVPDje7AmZZBuF2l0iandlUBjJVA%2BarD6dWVv8LNrv3RVyheuhBreAr7dLcSD4Iu44MH76tOZS%2BuMnqqFjKwC37owAdC7xtJwOIF8wrFM272qHnzxbfvZRaJruoG6WO%2F%2BMGJLPnaNbrhfJ99%2BtvCybb0CsVMQqJ%2FsUWM8Z89ci6a4MCPE41v1i9lXyvkZDm6qfoVgKVPUHVVsjbvuu5Ub7MeMgBsl76ZrRsi9yLiHmPLQGqhzxydy14GpCNH9FFM2BdRSlkxfBYV1yzX2Ym4gZMq6myvVsCTDgHeGXeQe%2F%2F7z6lLE3S0%2BgcA6NkuhfLU7lvAl0CguRAvU3%2FlVh3R1p8C9S3BXQak6eM0xYp7hO1wQKXMq4uMM2FjmtTUYe6ZiqyjGbkTrrIEkD%2Fo%2FX1NXXylMbWxuNyoTnQXx%2BQzDsUrY3Mhtb%2FslwCGDY4puOlwiVqGg31EBz0wFWzJFX7n2uQO76g5q%2FnTJqf3dq3AdTC6xpaGC2kek0fxc6FEDdaoVeQ3PwJWYi1kcPbwkcvo4gIi03rcO3JUJZF3TfomkFs%2BFnh%2FwLJHs%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670569138", oauth_version="1.0"
Content-Length: 275
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&card_printed_name=Test%20Test
&client_orderid=34T43R77N
&credit_card_number=4047753518764320
&currency=USD
&cvv2=123
&deposit2card=false
&expire_month=12
&expire_year=2023
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Fri, 09 Dec 2022 06:59:20 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddc004
&merchant-order-id=34T43R77N
&paynet-order-id=6863822
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A61365A5A5637456C4545743867705438697A512F30633D
```

**Fail Response Example**

```html
HTTP/1.1 403
Server: server
Date: Fri, 09 Dec 2022 06:45:14 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>403</title>
    
</head>
<body>
    <p>Access is denied</p>
</body>
</html>
```

##### Transfer from RPI to Form

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="y03UAVaLM9NXEwAHD0R9YDCQQFzRWx8b", oauth_signature="Zgx05s2b%2Fr4wSbo0sb2tGXbhPeDYlfJfnziSH57mkYfEMNtGoWCeUlLanQLKq1ddusIBhGUFwpwoh5f22y9tqHRsekiAQ92s9ixQxmvE8sEV3Ov%2FHoTyktrxN0vhPxuwSmwD%2FhX%2FOMJgDaCoOZK%2BxeXfPRVRwlNM8LsDd29i%2FnIUsExWCBujs3M5ThYGz58UJdZmOxrWW3poH2Lb6Fw9b6XMwV2DzvyomhMzZfyQYYX%2BhP22rCmXTg%2BEyTVnJDBiWI3pF6WYQFjdO5tPbcK4bxw4IYNIKKEi78dw0%2FZcb65gfHlaUtqHd3ZXiFiob4YFeV%2B1XKI2wSVBVemEd3jVjOFXDZv2GLzrZOUkxcns6BqkRxMqaWc9%2FbpsL65XdFxB4LUuP2h1PVk6A5yjjanSjp1XqzyAx8EGpxYGAzIPNSsYPVN9x5TuyIqtYVXhz2y0z8RPx5VFmSYr%2BaCr6ruhRNkyonNmk47oPkIkG9PpLivBaq8PnIzUNpExTRIYJXJOwD69CjCPxT%2Fhr3udDQJD4ZHFE3TNA9g1H0VRL%2Ff60jPhZeanf9MgcFqz6jckPQghBixOaTBf9DmP9jmv12IQZ3PR3J3n53nDEUIw%2Fhiga3%2BdZswkJMYS57VB282SVfDXQPO%2F40OC%2B3annev%2BMftiSfChhRgazDRToCnbETXqoKc%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670850681", oauth_version="1.0"
Content-Length: 266
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&card_recurring_payment_id=1491854
&client_orderid=34T43R77N
&currency=USD
&cvv2=123
&deposit2card=false
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 13:12:21 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddc34e
&merchant-order-id=34T43R77N
&paynet-order-id=6863959
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A5A716755336669466574615739747A737059777A50493D
```

**Fail Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 12:25:05 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 176

type=validation-error
&serial-number=00000000-0000-0000-0000-000002ddc2ec
&merchant-order-id=34T43R77N
&error-message=Src+card+cvv2+should+be+filled+in+transfer.
&error-code=29
```

##### Transfer from Form to Form

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="3FUX1QCRBPF7am99UO4bty1qD7FK08I8", oauth_signature="CCvlgjfVBZOwoMS%2FbUXv1LiRlc0Nu3Owf3FwNmPnbP49RWi3ve3VE9Jt61QpRx14pmCz3xFKQt%2Bi4UvXJYlsn206TSZ9H7TGCSHhQQP5vD0mm3Pnq0YgtI2oPpn2PhgM%2FlgwwWcBjBqmCyzM%2FGGqK24zn5C20bxvHL9LfuMgF4bEpIYDGXVh3%2BbhlU5Z2H25fjjttZylm1SLhAi9lOct2%2BtH00TJ%2FgjdWR%2FCnIroLVPWqnYbE8f%2F%2Bz1HuynqW684UUaAiB8WgEulH1BBM6HqYiFAVyfWlLNzDv08cKZew7JPsso17XBdqYyE2QWkREM61FPSQpQsuAnRpezxjRZnmxsShXKqgNwj%2B%2BVeEEP7Z0IFqUreDgSYYSntrgtvZHhX6oNuEn4V8jWA6TO0wPNPKqkEXTk7w53nF0Hn%2FLgAa3FfYSHtCnFP1uELmPnVrO03IWaPPw0%2BcCJzNMua7g%2FYjlCsdV3tlwUwne1R0V3togR5k%2FTnG%2Bub4txjaFeqOm9p517ppKZQn8Fe0jtIIJMCYVRVmsYkeBZyyRgcdIBOAn09fCKZ7y74gI12py%2FvVzagFCjZo05T20gY6OpCkrP4HhWEkKJhrqSCBe7NLC1xZDszfkLFjF9Z4dWvk2PIcNfI3SGYZRks0YFPECycfYzYIJfuKplYAACzR47h30SaOiI%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670835177", oauth_version="1.0"
Content-Length: 167
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&client_orderid=34T43R77N
&currency=USD
&deposit2card=false
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 08:53:26 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddc1f8
&merchant-order-id=34T43R77N
&paynet-order-id=6863917
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A613368326D746C2B72645043314744502B537A6E57343D
```

**Fail Response Example**

```html
HTTP/1.1 403
Server: server
Date: Mon, 12 Dec 2022 09:18:33 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>403</title>
    
</head>
<body>
    <p>Access is denied</p>
</body>
</html>
```

##### Transfer from Deposit to Form

**Request Example**

```http
POST /paynet/api/v4/transfer-form/39915 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="SDrbaim155azbf2UthcVDrhwiOA6liE4", oauth_signature="CFUUC1Y6QT5Gj7LA%2FdW6gkGN%2Fh73J8HAxhvYtFx%2F%2FChlQIU7f4uvVmKpOossrRD05wdx0ENHJZLZ8SI%2B610ygcWP%2B3K%2FqEYDI7qjdg8HgKlT3BnjSoGU6EjGjvcMwQSY0AwNJ4adYYZG6G%2Ble9SOvbPcQalkfxIjpTl%2FkyrIVtNS4h9ExkD%2Fg9UUXZ%2F2YAOCyhTy26QwOLOo5NmNeh%2FX7wpqPEyjHfEE%2FWbc3iSNSjlJA9b%2BfX5eFAVxzzZ2X76HRxy%2FuHqah9NszgXsagMHpXOpvovNRLEh7NFBqVDWhoHFfDS%2Bwd6vcLqXxwLKOVecmq06GN1%2BiZX4C9QebaNw6JSx72jMon3hnn37pUSLhzWXz%2BwlMX7XN%2FcTWsZ0kL51DzFXwPAJPVAeNevgxlaFtbELMGcZNOU19u72cOZKMu7%2FsxLAfCgUITCO2NhvZw%2BR8xUZUcxvwu4fvoTXr6rf8r0iloJIA9RoaKobzmPUDcGx3%2F4Hswjbqk7YOg6jxQJD6ZoKscHpLiQLvBWPILsSVMpQUpnUqzBNGexdCd8zaRzqiszwz4hEg6teTMFOLA%2FoQ8Wu%2FxtSs8JMuXsWtestY9h1y5KuXWDy8O9hpN45pBF%2BvtoDfyr6ktKrkZZTZG49FBKk%2FcKi5FjzL5Bsbwv9fgk1%2BRYDexMtHCqX%2Fdrz%2BzMM%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1670851416", oauth_version="1.0"
Content-Length: 166
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=100
&client_orderid=34T43R77N
&currency=USD
&deposit2card=true
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200
Server: server
Date: Mon, 12 Dec 2022 13:23:58 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 285

type=async-form-response
&serial-number=00000000-0000-0000-0000-000002ddc35a
&merchant-order-id=34T43R77N
&paynet-order-id=6863960
&redirect-url=https%3A%2F%2Fsandbox.payneteasy.eu%2Fpaynet%2Fform%2Finit%2FBB587546567A31587163597A684535634A775969614A5878476D6E717A31324167486F61674C6830743070343D
```

**Fail Response Example**

```html
HTTP/1.1 403
Server: server
Date: Mon, 12 Dec 2022 13:19:46 GMT
Content-Type: text/html
Content-Length: 735
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

<!DOCTYPE html>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
    <title>403</title>
    
</head>
<body>
    <p>Access is denied</p>
</body>
</html>
```

### /api/v4/transfer

#### Introduction

Transfer is a type of complex transaction that allows to move funds between bank cards (Primary Account Number - PAN), card tokens (Recurring Payment ID - RPI) and Connecting Party bank account (deposits).
 
Transfer is initiated through HTTPS POST request to the [URL](#transfer-api-urls) with the [required parameters](#transfer-request-parameters-description) depending on a certain transfer Use-Case (see below). Some integrations might require [Additional parameters](#transfer-additional-parameters). Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 
Possible transfer Use-Cases:
 

| PAN to PAN | Transfer from PAN to PAN occurs when transferring funds from one bank card to another, when specifying for each card their card numbers, and not the recurring payment id. |
|----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| PAN to RPI | Transfer from PAN to RPI occurs when funds are transferred from one bank card for which its number is indicated to another bank card for which its recurring payment id is indicated. |
| RPI to PAN | Transfer from RPI to PAN occurs when funds are transferred from one bank card for which its recurring payment id is indicated to another bank card for which its number is indicated. |
| RPI to RPI | Transfer from RPI to RPI occurs when transferring funds from one bank card to another, when specifying for each card their recurring payment id, and not the card number. |
| Deposit to PAN | Deposit Transfer to PAN occurs when funds are transferred from Connecting Party account to a bank card by its number. |
| Deposit to RPI | Deposit Transfer to RPI occurs when funds are transferred from Connecting Party account to a bank card by recurring payment id. |

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------|-------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/transfer/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/v4/transfer/group/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/v4/transfer/group/ENDPOINTGROUPID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

PAN to PAN

| Parameter | Description | Value |
|-------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| credit_card_number | Sender\`s credit card number. For the scenario of payment from a card inside the system, this card will be considered as a source. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four-digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| expire_month | Sender credit card’s month of expiration. | `Necessity`: Required `Type`: String `Length`: 2 |
| expire_year | Sender credit card’s year of expiration. | `Necessity`: Required `Type`: String `Length`: 2-4 |
| card_printed_name | Sender\`s card printed name. | `Necessity`: Required `Type`: String `Length`: 128 |
| destination-card-no | Receiver\`s card PAN. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| destination_expire_month | Receiver credit card’s month of expiration. | `Necessity`: Optional `Type`: String `Length`: 2 |
| destination_expire_year | Receiver credit card’s year of expiration. | `Necessity`: Optional `Type`: String `Length`: 2-4 |
| destination_card_printed_name | Receiver\`s card printed name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

PAN to RPI

| Parameter | Description | Value |
|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| credit_card_number | Sender\`s credit card number. For the scenario of payment from a card inside the system, this card will be considered as a source. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four-digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| expire_month | Sender credit card’s month of expiration. | `Necessity`: Required `Type`: String `Length`: 2 |
| expire_year | Sender credit card’s year of expiration. | `Necessity`: Required `Type`: String `Length`: 2-4 |
| card_printed_name | Sender\`s card printed name. | `Necessity`: Required `Type`: String `Length`: 128 |
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| destination_card_recurring_payment_id | Receiver\`s recurring payment ID. To create destination_card_recurring_payment_id please see [Card Reference ID Creation](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Long |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

RPI to PAN

| Parameter | Description | Value |
|-------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| destination-card-no | Receiver\`s card PAN. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four-digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| destination_expire_month | Receiver credit card’s month of expiration. | `Necessity`: Optional `Type`: String `Length`: 2 |
| destination_expire_year | Receiver credit card’s year of expiration. | `Necessity`: Optional `Type`: String `Length`: 2-4 |
| destination_card_printed_name | Receiver\`s card printed name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| card_recurring_payment_id | Sender\`s recurring payment ID. To create card_recurring_payment_id please see Card Reference ID Creation. For the scenario of payment from a card inside the system, this card will be considered as a source. | `Necessity`: Required `Type`: Long |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

RPI to RPI

| Parameter | Description | Value |
|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: False `Type`: Boolean |
| cvv2 | Sender\`s CVV2 code. CVV2 (Card verification value) is the three of four-digit number farthest to the right on the flip side of a credit card. | `Necessity`: Required `Type`: String `Length`: 3-4 |
| destination_card_recurring_payment_id | Receiver\`s recurring payment ID. To create destination_card_recurring_payment_id please see [Card Reference ID Creation](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Long |
| card_recurring_payment_id | Sender\`s recurring payment ID. To create card_recurring_payment_id please see Card Reference ID Creation. For the scenario of payment from a card inside the system, this card will be considered as a source. | `Necessity`: Required `Type`: Long |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Deposit to PAN

| Parameter | Description | Value |
|-------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| destination-card-no | Receiver\`s card PAN. For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: True `Type`: Boolean |
| destination_expire_month | Receiver credit card’s month of expiration. | `Necessity`: Optional `Type`: String `Length`: 2 |
| destination_expire_year | Receiver credit card’s year of expiration. | `Necessity`: Optional `Type`: String `Length`: 2-4 |
| destination_card_printed_name | Receiver\`s card printed name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

Deposit to RPI

| Parameter | Description | Value |
|---------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| deposit2card | Marker of Deposit to Card transfer. If true, no sender cardholder data is needed to process the transaction. If false, sender cardholder data is needed. | `Value`: True `Type`: Boolean |
| destination_card_recurring_payment_id | Receiver\`s recurring payment ID. To create destination_card_recurring_payment_id please see [Card Reference ID Creation](https://doc.payneteasy.com/integration/api_v4_create-card-ref.html.md). For the scenario of payment to a card inside the system, this card will be considered as a destination, and all processing limits, lists and fraud scoring will be applied to it as a destination card. | `Necessity`: Required `Type`: Long |
| ipaddress | The Sender or Receiver’s IP address, include for fraud screening purposes. NB: 45 is for IPv4 tunneling like 0000:0000:0000:0000:0000:0000:192.168.100.101 | `Necessity`: Required `Type`: String `Length`: 7-45 |
| client_orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| currency | Currency the transaction is charged in (three-letter currency code). Example of valid parameter values are: USD for US Dollar, EUR for European Euro. | `Necessity`: Required `Type`: String `Length`: 3 |
| amount | Amount to be transferred. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| purpose | Destination to where the payment goes. It is useful for the Connecting Party who let their clients to transfer money from a credit card to some type of client’s account, e.g. game or mobile phone account. Sample values are: +9999999999; [mail@example.com](mailto:mail@example.com) etc. This value will be used by fraud monitoring system | `Necessity`: Optional `Type`: String `Length`: 128 |
| redirect_url | URL the cardholder will be redirected to upon completion of the transaction. Please note that the cardholder will be redirected in any case, no matter whether the transaction is approved, declined or in any other final status. Optional for direct integration (non-form) deposit2card. | `Necessity`: Optional `Type`: String `Length`: 1024 |
| order_desc | Order description. | `Necessity`: Required `Type`: String `Length`: 64k |
| server_callback_url | URL, where the transaction status is sent to. Connecting Party may use server callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to server_callback_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of notify_url. If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| notify_url | URL, where the transaction status is sent to. Connecting Party may use notify URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. For the list of parameters which come along with server callback to notify_url refer to [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). This parameter can be sent instead of server_callback_url. If notify_url is sent, Payment Gateway sends callback notification once the original transaction receives final status, and about every future update for this original transaction (reversal, chargeback, etc). If server_callback_url is sent, Payment Gateway sends callback notification only when original transaction receives final status. | `Necessity`: Optional `Type`: String `Length`: 1024 |

#### Additional Parameters

##### For Connecting Party

Use additional parameters for Connecting Party to specify Sender’s browser information and Connecting Party 3DS results notification URL.
The Connecting Party’s site needs to accurately populate the browser information for each transaction. This data can be obtained by Connecting Party’s servers. Ensure that the data is not altered or hard-coded, and that it is unique to each transaction.

> **Note:** These parameters are not applicable for cases `Deposit to PAN` and `Deposit to RPI`.

> **Note:** Browser data for 3DS 2. X is gathered by payment gateway system on 3DS authentication stage. For some processing channels, however, the browser data and/or connecting party URL for 3DS challenge results must be provided in initial transaction request. Please contact Support manager to clarify if these parameters should be included in request parameters.

| Parameter Name | Description | Value |
|---------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------|
| tds_areq_notification_url, alias tds_cres_notification_url | Fully qualified URL of Connecting Party system that will receive the CRes message or Error Message. This CRes message must be sent to Payneteasy. See details here [Upload CRes Result](https://doc.payneteasy.com/integration/upload-cres-result.html.md). | `Type`: String `Length`: 256 |
| customer_browser_info | If true, then the fields below must be present. | `Type`: Boolean |
| ipaddress | IP address of the browser as returned by the HTTP headers to the 3DS Requestor. | `Type`: String `Length`: 45 |
| customer_browser_accept_header, alias customer_accept | Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder’s browser. | `Type`: String `Length`: 2048 |
| customer_browser_color_depth | Value representing the bit depth of the colour palette for displaying images, in bits per pixel. Required when browser_java Script_enabled=true. | `Type`: String `Length`: 2 |
| customer_browser_java_enabled | Boolean that represents the ability of the cardholder browser to execute Java. Required when browser_java Script_enabled=true. | `Type`: Boolean |
| customer_browser_javascript_enabled | Boolean that represents the ability of the cardholder browser to execute Java Script. | `Type`: Boolean |
| customer_browser_accept_language, alias customer_accept_language | Value representing the browser language as defined in IETF BCP47. | `Type`: String `Length`: 8 |
| customer_browser_screen_height | Total height of the Cardholder’s screen in pixels. Required when browser_java Script_enabled=true. | `Type`: Numeric `Length`: 6 |
| customer_browser_screen_width | Total width of the Cardholder’s screen in pixels. Required when browser_java Script_enabled=true. | `Type`: Numeric `Length`: 6 |
| customer_browser_time_zone | Time-zone offset in minutes between UTC and the Cardholder browser local time. Note that the offset is positive if the local time zone is behind UTC and negative if it is ahead. Required when browser_java Script_enabled=true. | `Type`: String `Length`: 5 |
| customer_browser_user_agent | Exact content of the HTTP user-agent header. | `Type`: String `Length`: 2048 |

##### For Payment Institutions

The Payment Institution can fill the 3DS results for each transaction, if 3DS authentication is performed on their side.

> **Note:** These parameters are not applicable for cases `Deposit to PAN` and `Deposit to RPI`.

| Parameter Name | Description | Value |
|------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| tds_authentication_result_type | Type of result. Possible value is: SIMPLE | `Type`: String `Length`: 6 |
| tds_authentication_result_authentication_type | Authentication Type. Indicates the type of authentication method the Issuer will use to challenge the Cardholder, whether in the ARes message or what was used by the ACS when in the RReq message. Possible values are: * 01 = Static. * 02 = Dynamic. * 03 = OOB. * 04 = Decoupled. * 05-79 = Reserved for EMVCo future use (values invalid until defined by EMVCo). * 80-99 = Reserved for DS use. | `Type`: String `Length`: 2 |
| tds_authentication_result_authentication_value | Authentication Value. Payment System-specific value provided by the ACS or the DS using an algorithm defined by Payment System. Authentication Value may be used to provide proof of authentication. A 20-byte value that has been Base64 encoded, giving a 28-byte result. | `Type`: String `Length`: 19-28 |
| tds_authentication_result_transaction_id | xid for 1.0.2 or ds TransID for 2.1.0/2.2.0. | `Type`: String `Length`: 19-36 |
| tds_authentication_result_transaction_status | Transaction Status. Indicates whether a transaction qualifies as an authenticated transaction or account verification. Possible values are: * Y = Authentication Verification Successful. * N = Not Authenticated/Account Not Verified, Transaction denied. * U = Authentication/Account Verification Could Not Be Performed, Technical or other problem, as indicated in ARes or RReq. * A = Attempts Processing Performed, Not Authenticated/Verified, but a proof of attempted authentication/verification is provided. * C = Challenge Required, Additional authentication is required using the CReq/CRes. * D = Challenge Required, Decoupled Authentication confirmed. * R = Authentication/ Account Verification Rejected, Issuer is rejecting. | `Type`: String `Length`: 1 |
| tds_authentication_result_message_version | Message Version Number. Protocol version identifier This shall be the Protocol Version Number of the specification utilised by the system creating this message. The Message Version Number is set by the 3DS Server which originates the protocol with the AReq message. The Message Version Number does not change during a 3DS transaction. Possible values are: * 1.0.2 * 2.1.0 * 2.2.0 | `Type`: String `Length`: 5 |

##### Sender Customer Data

Parameters below can be required for specific integrations. For more information, please contact Support manager.

| Parameter Name | Description | Value |
|-------------------------------------------------|------------------------------------------------------------------------------|------------------------------------------------------|
| sender_first_name | Sender’s first name. | `Type`: String `Length`: 128 |
| sender_last_name | Sender’s last name. | `Type`: String `Length`: 128 |
| sender_middle_name | Sender’s middle name/patronym. | `Type`: String `Length`: 128 |
| sender_ssn | Last four digits of the Sender’s social security number. | `Type`: String `Length`: 11 |
| sender_birth_place | Sender\`s birth place. | `Type`: String `Length`: 128 |
| sender_birthday | Sender’s birthday. | `Type`: String `Length`: 30 |
| sender_address1 | Sender’s address. | `Type`: String `Length`: 256 |
| sender_city | Sender’s city. | `Type`: String `Length`: 128 |
| sender_state | Sender’s US states (two letter abbreviation). Not applicable outside the US. | `Type`: String `Length`: 4 |
| sender_zip_code | Sender\`s zip code. | `Type`: String `Length`: 32 |
| sender_citizenship | Sender\`s citizenship. | `Type`: String `Length`: 128 |
| sender_country_code | Sender’s country (two letter abbreviation). | `Type`: String `Length`: 2 |
| sender_phone | Sender’s full international phone number, including country suffix. | `Type`: String `Length`: 128 |
| sender_cell_phone | Sender’s full international cell phone number, including country suffix. | `Type`: String `Length`: 128 |
| sender_email | Sender’s email address. | `Type`: String `Length`: 128 |
| sender_resident | Is sender a resident? | `Type`: Boolean |
| sender_identity_document_id | Sender\`s identity document name. | `Type`: String `Length`: 128 |
| sender_identity_document_series | Sender\`s identity document series. | `Type`: String `Length`: 12 |
| sender_identity_document_number | Sender\`s identity document number. | `Type`: String `Length`: 16 |
| sender_identity_document_issuer_name | Sender\`s identity document issuer. | `Type`: String `Length`: 128 |
| sender_identity_document_issuer_department_code | Sender\`s identity document issuer department code. | `Type`: String `Length`: 32 |
| sender_identity_document_issue_date | Sender\`s identity document issue date. | `Type`: Date |

##### Receiver Customer Data

Parameters below can be required for specific integrations. For more information, please contact Support manager.

| Parameter Name | Description | Value |
|---------------------------------------------------|-----------------------------------------------------------------------|------------------------------------------------------|
| receiver_first_name | Receiver’s first name. | `Type`: String `Length`: 128 |
| receiver_last_name | Receiver’s last name. | `Type`: String `Length`: 128 |
| receiver_middle_name | Receiver’s middle name/patronym. | `Type`: String `Length`: 128 |
| receiver_birth_place | Receiver\`s birth place. | `Type`: String `Length`: 128 |
| receiver_birthday | Receiver’s birthday. | `Type`: String `Length`: 128 |
| receiver_address1 | Receiver’s address. | `Type`: String `Length`: 256 |
| receiver_city | Receiver’s city. | `Type`: String `Length`: 128 |
| receiver_state | Receiver’s state. | `Type`: String `Length`: 2-4 |
| receiver_zip_code | Receiver\`s zip code. | `Type`: String `Length`: 32 |
| receiver_region | Receiver\`s region. | `Type`: String `Length`: 30 |
| receiver_area | Receiver\`s area. | `Type`: String `Length`: 50 |
| receiver_citizenship | Receiver\`s citizenship. | `Type`: String `Length`: 128 |
| receiver_country_code | Receiver\`s country (two letter abbreviation). | `Type`: String `Length`: 2 |
| receiver_phone | Receiver’s full international phone number, including country suffix. | `Type`: String `Length`: 128 |
| receiver_email | Receiver’s email address. | `Type`: String `Length`: 128 |
| receiver_resident | Is receiver a resident? | `Type`: Boolean |
| receiver_identity_document_id | Receiver\`s identity document name. | `Type`: String `Length`: 128 |
| receiver_identity_document_series | Receiver\`s identity document series. | `Type`: String `Length`: 12 |
| receiver_identity_document_number | Receiver\`s identity document number. | `Type`: String `Length`: 16 |
| receiver_identity_document_issuer_name | Receiver\`s identity document issuer. | `Type`: String `Length`: 128 |
| receiver_identity_document_issuer_department_code | Receiver\`s identity document issuer department code. | `Type`: String `Length`: 32 |
| receiver_identity_document_issue_date | Receiver\`s identity document issue date. | `Type`: Date |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Parameter | Description |
|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Connecting Party order ID. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| end-point-id | Endpoint id used for the transaction. |

#### Request & Response Examples

##### Transfer from PAN to PAN

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="aGDxlipOs21lzMdyp0TGmCltVbBgnaUh", oauth_signature="R6uBD0TnC75UmYVFqEf70YX9tKK7iRmBR%2FoJGPCUTwzzyjtkAg6jK8fk2I0EbzeadqTLDgckrXShSsD5Ke8%2FP3ZqPwWwh3OMT5XK9MWVcDGavjKQi%2BnXfJdr4JRbhPAk1YL3IJL04TTTmAoJHFWu0EKNdzndAMQ0cWay4Hg5evPcDpJEK0a2ZaKnSMjh9UMmttvzDL4Cb2INDH%2F5VadKPji%2FbDAxxWVT%2FQ9HVJcVSDHlxFniLBgyJr4ZIg4ROwtnO3hbOC%2FC5rf7USgjkbpkBUejqjk4Wgw%2BJHMFJ4PJQM0beYn1ctmVGg27MOp8UWyi2i3PsAy8FbPf%2Ff6sMTDhx8MABfbIojHgrvke%2B3flfS%2BUmtCo5pQ%2F9blWvVmB%2BjJz%2BqznYEAUk%2BHj7ekSVzMvpf5LNDeIwpwSVEZpp5Ig8OyKZcWe9i8bbmfDsWehSGpiVkaraWsLCToras3lZy73Hp5z6SN8Uc98f%2BXUF8ROJvSysAfzDU2BJrDhNo1tKjuhY%2FEQzEinYe0zCSsSHOhkl2yU2KwWxbgWXb%2FoMEHIuuZ5l%2Baa%2FGTLSCb%2Bm5wJ8n9QeDSulHM3VmTP%2F7wFXa5DwCQCDy3Lu7vOWVFhLirXOMH6V%2Fe5SZ1yQHo0uH2N7F72DGKrcNkvkLaZCB4NE8AVqISxB484AB5Mo0pC3iZzAPWNo141iezgrlacarwSNsqSwmGBfvCWAkxszqIHgWWOfsomfG4OJTo%2BRgtO6SkLAgpPcGDYWjziDvT6uQvAQG3R5aSv6OgrjZNn0PQqsWb4qT7nlirHLwXXrSL46HTRyCl9q4QCuufKPZA0LOW3y7OJsk2T%2BuI%2FZHXzDOeHGIhxBWa%2B%2BrpYhwDzmx1736gnNZ6dBbzKz5hH20BWOzvaZ93mKDH32Ri62D4yvAf64ElvSdNSImImLtEstRcws9YBsdcAxJw0TXICclwN8DM39jhU7ekc2XsYhmCeEk5f1OL6a0Ud6IyxZN0HLhOPRHHSiiMh90y1DOyk%2FUSjihshg2NDmFJe4TNZ7TZRzlD5WKR6FxeTH6xYq1RJvoHiC0SUyVKjX7knFp%2FIEx3fdpMRD8ZCT%2FgUw5Cu34q87B7xVLHjEhn9%2FV3lacVDJ48F1aS6urv%2FI2cahSsIz288g1V1ThhrusN7TMdIsoZ%2F7XqKxht3p34N0e7lDUVils42ySmZil78GVvr9wR2GtOpa8FT31F0LnyVxCiA3Fqj5LNM3QunElqSaNXI%2BtwlzKFGq4oklwb7bilOin0uzYlb4ymz7x6o7O8dJmCeUpkfCUxFrQnpmmHGBg0VgcKS5S769otXsXICqMP%2BDU2x5dajQvbIlzzm4aKF4qm2jxSowydOWU1Y28Q%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1661493794", oauth_version="1.0"
Content-Length: 305
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&card_printed_name=John%20Doe
&client_orderid=1
&credit_card_number=4332435659564446
&currency=USD
&cvv2=123
&deposit2card=false
&destination-card-no=4998406231653309
&expire_month=12
&expire_year=2099
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Fri, 26 Aug 2022 06:07:43 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddaf96
&merchant-order-id=1
&paynet-order-id=6863038
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 09:53:35 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [1ee76b38-3764-407e-9dfb-2ffc9ab0775b]
```

##### Transfer from PAN to RPI

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="yL2jqiO6NnIVBGhT3ocsWDgsaYxG3P7j", oauth_signature="U5FwR96T0huNFmDQYivbEkLFISfZKF%2FREN%2BwBXLNAD8K0HAAXh0FbmXDSkgvsZXb4i1UPc1xFmqvIX2lYsiZRixMesiRIbAhoHsmHHpGfZ5hS2YMfVAUQWfVbHdqCJQZEJofu7RM1ow8rS0YbGCYvqSHUbI0bDi%2FpXERzDrr5N76AOhl2onBPjqXQqhAdVYBfTUHhezDJChhyg4Lc4gkRsVbw8tIbx220vCT57t9CQhYvNd9bONH6Vkn6XyUVY3bfi%2BNt4CQ25W2F%2FpYVK2%2BtLeCVDHytY7JGaUalWKXg2HIhr2Olmh9GRSZ51tenAL%2FgkHI%2BDsIh5nn6nsBAMFnSCQR7ANy7cUpLw5KZnQLKLFcCeNeBdFqXDwZ2aOX1PDdHvn1KZBtf1SqGp3kkEX3AMin%2F3QTOHobLRFAwGBIExwGxOddRL2mPIOUMvF6CE%2FGgBGHstcjyDCAQ3U2n%2BXlaM1cCgWtLL2A5nBM2%2FMnCUqqYUY4eN2Gidh2ZoLw70v%2BL4jLnK3%2BKefRxyPgOlZQBxH1qfP3tayZlMIdJ8gAdAmx2RlK%2B3krUsy4TSpCzyAX4xloovGgC9yP0u0u4jJT6DTSdTJ3IdiCoUTyAA%2BPdkRrMZ%2BswFRH%2FCU8HETuOGQHUCnbL10DjHCvvis3OtNH6j1aNETfWJqJ29lSngs8%2BU0Q%2FlAGdlRXdAVkqj5Vd5wfLeMvSgjmhPbS6Cfk60hXS%2Bj58DPdlKZ8Itg7gZO%2BW%2BGNfpwkD2baTdAiMjU%2F0ZGx9UW9caT1QrsXL6ub4NXQHnHluCqHH%2Fi6zNOu2pAuHcuJ%2BOLOzcPSDRCFeOk2zy2SAiWKTKWEFypMg2AQuRydrB9ZFPnmVokPnN4Y99ZSdj1PD3VOuXCW1h7AjGub8oMYCaqOvcB8bdSg%2BJYnkWS5CMsQSMjuW5ZhRCtGYlrpq3luQS25h5LLXi3OrqkiQdst0I9lTmmzwQ0OiFmXPcH7nKE8gantsa5hs7BVgPeypY%2BKfVZiqs9w6y2aq%2F9CUtatVj9%2BU56%2FucDhs2b9s6kY3kbvO3p568hlJHvNxgyhv0eGfMSyWjmil3OuZf0VsNlbptGC69nIlXKXgV7sX3B049gN%2Biw08EP8tfpZPE%2BFViY8ecDrs2CquzJpZvOFX4WZ2bbIr9%2BOOcVMhGJ7QrFC96ddnbhfGaDJsc2FCgjBNQJvZJ8Mhxa7kksHujdxFrBa%2BKGSs0qROwTcpxRtb4zBDEcq%2FHklBkB0T6lOWpYvkhUy1coF8KtuhPSfqhkVg6gB5%2B%2BLgGK6DQKIoMI9MvzSLTOR9ElE9vWUUMP1eG2b46jqOiIuAwQvJZfnxqlizF5OcqBbJazBj7t%2FiH0KKPvO6Q%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1661494949", oauth_version="1.0"
Content-Length: 303
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&card_printed_name=John%20Doe
&destination_card_recurring_payment_id=1491828
&client_orderid=1
&currency=USD
&cvv2=123
&deposit2card=false
&credit_card_number=4998406231653309
&expire_month=12
&expire_year=2099
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Fri, 26 Aug 2022 06:22:43 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddafb1
&merchant-order-id=1
&paynet-order-id=6863042
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 12:30:15 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [18819567-ab17-4342-86eb-f8a45966e8c8]
```

##### Transfer from RPI to PAN

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="J5wfdvnj45sDN2TElY2nIHcpDgIPsEa5", oauth_signature="VhvXrMZNTrRxBCd7AOtRWcqc67KLyD6wQpJoVuJP0I4%2BWseXd5bAfMZtuy1QBhVGMlGiVfl97tmiB1LzSTnWcA%2BlS8bCyEXgoE0XL4rn3U2rXV2JWgPTrv1EHCaAt%2FJhZ1JPd6kjzGG3ZDJXAZg3YMoRdL00iK66Z1AK%2BhuL1M9mziEkcvZZR3elREmz%2F223aVXRr%2BXc6dWFTHQM9BDTsVarsHrYHv9TkBjDbYXp%2F%2BX9ltfdUV7YXGemd6jy25CbJC9zbTj1wHsrpT2bkbBCpycH8xtANFAeQgyTpR4IU4OglzPSunXeZaO9o1%2FwzWEvDmHN4g0WRnyl%2Bmgy7qU3wvMyyDf27UCRXFgEmfybk%2Fa3bwouJUqQbYUMif%2FGULsPmdSmz%2FWhmPnyIq9lvNkExE4xIXB1j7C8aYGoSRavvdhmEcNIbyXEs6hur%2FmXkIJH5RHDJTAcfu7RHkRUd3jBQjEEI1q9HnhTmdHKOEovQs%2BzR3K7Fv6%2FLW71cmbMMpqYbkIaBVN0%2Fdx4jLwZwqbk3B6PxxAyf6f48vJDFoNqVrlpaGXWTwZaeLWlE0sCgk3Cscss64%2B%2Bt8eHaVRS2u09uwvlh9iCSqXeZjikHB782u7xc6f8PWp70xK0DsBsN1QyN1%2FLMH1ozr1HsYvZrucC8C7T2BykksEKmitpZ0cRUsj7Hb59nh39xk%2B8Vk1VenfUyz7O%2FnMsOeuKna0RHLI35DqgnvPp0yjU2SqM32N6%2B7Dtaa135N7oC1z8hG1zCB2C%2F%2Bk9Bmt0y%2Fad6yiEMN%2F%2FslGob7U5x82Sf7ph92EFCPu1ccW%2FMbxb9xu8csaMHDbh7E%2FydQm3WOym0U3%2FPSckea23YOTScrr0mQsGOjBwzgehUsJyCyLiWehFob6aEfuphXfdiyb5vXUKZuTAWPofgusJByrOHErhfPgQoUJ96YXfGGFTZAlLP8G5T14ZM02JrWffGGuvDzZiwkK8s9%2FPfZxTCQxjmM%2FIOOkSY48PTjYVq36V7x2v%2FDzJeux1Txu4TpewUod1ZDhxzu8kUEgKgxtJalPcFuZL8dwTynb4LCoKEK8mM15MRXWpHJzJ4k9yH1Rrn8bfEcQWUI5bdgsEdgWRBNMevwRGb3E%2B2ZMO5XihaKA1eCxBtKtxIvNShKjqS5fYdUfRHf5yVRwE67EZx9zAj1lHvTPSB1q1foWbU5MhN9vNc36hkLLsCjiKZsRctGFZGwTrgb6sPMrPoqpj8h66RosFHvi116G2sWe4jlz7OhC2%2BYD%2BQsMiiEIPmlHLWf2Z1w8g7NK%2BigKPI13hyLeOavPDEzV1ngy1XqkIdQdLS1mxxpD8sw9%2F0h4iN7kDgRC3eSwM97%2BO%2FdaN0d14JQ%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1661496079", oauth_version="1.0"
Content-Length: 314
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&client_orderid=1
&destination-card-no=4998406231653309
&currency=USD
&cvv2=123
&deposit2card=false
&card_recurring_payment_id=1491828
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Fri, 26 Aug 2022 06:41:34 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddafb6
&merchant-order-id=1
&paynet-order-id=6863043
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 12:34:35 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [ea7cab67-2af5-408a-aa76-79bba38688cf]
```

##### Transfer from RPI to RPI

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="AC4qZJfR4OZW8xiNX9SrWj5upjPZ74kU", oauth_signature="mF%2BUTmlP7hbIMlfHCbuxDiq%2F3nx6l04zuWZpkVdnw03OHiyNBGdEg2rIsg1SZAg3Eu8VUXGBePyK0wksnyIgcyTigP5apTLrz%2FgpE4o%2BHtP%2FfJ%2B04qQ4fV5WH0RqPjd9xBEaD2JO%2Foe6xYg3tx4u1QZ1MyrQjcJTrpbn%2BOxnia8%2FFruu4Crs3KHLmiUBSSVc9T9YlDu%2BuZfDBCxSqHs1j3T4JoCskfH8VHJ%2FI8igkh5e9qUYD4MrVunhsbcv8KHS0N%2Fb1f5b%2FcoH0QK9ERX7Smo7Ns9ErvbGjJtu%2BwFMffH8%2B4EExtzJbRKQRMYdnY6PxNiu66wzGuMVKCRdTvwc%2FisUnJ0LssFRwnFLamxrytoPj2I45rPkh08ydA2jYCAErR8FYAmk%2BiLrY9pLkAL21BgKLHw%2BJgxUeQAIqLwwHIaNA8AnzP9nvYGu9gRVYfei%2FZ%2Bue%2BqcXBAlDJIGYB0JTGHTEf8t2lOpiI0AEIM%2Fd%2FKF5%2BbPp52Xdde6aKV1FT2A5i8%2FCJEKxuh%2FMWwcSqa88T7m4swnzH879cnkqbgzmSl2PS49poiccDaUwC78ZCxwGVD73FUSsgBnO68kZVpYwBIat543EH1HCvG1sH1xV8Fp8uSBxnjahDGKmi67viQQPlvl5avULcqj9PylSHp%2B%2BMn3L1PPss2G2qai5ITLunNfyFXzofotvR7KrprM3EuZmB47eanQ0nxmpyvBI2BsvObO8bJ97EPSxjhIyjdYoTq8F2GEumMsqZCj6tHZFO9%2Fd7iSJvjfxHLa%2FIQjew%2BguK%2BTL%2Bw1lPCDq9monQ8EX7OT1kh91DVjlcxglqqxqpWt%2BWCY56ZXuEKZ6kqYjT6N2ab2bjGTiBrcgmToq7gvcbKdMCcqgzPJZR5tK%2Fc%2Fu2hepO2L0%2BU%2FzG9IB55iFoq2c2qG32T%2Bg8K54WGPAyzubkW3mKy9B8VwlzUu%2FWSKNQgtbf2pqVOLUZ%2FTCa1ood9CqfNF%2B2ECo8x1ubyyzbBaUIW86fA1cgXptgmJp6G5xapky877ND9XXBRlXvOS6%2BlcItiqB%2FfQEIs7awflpyRlGQQJttpGrJTqjYXiFbvmlA1Z98l8yZ2aZmDi%2BfxcGkICtnjUYZnlYU%2BO7Eo%2FlV%2BrcbQMQzXp6zYHd7hPTwuNZ0fS%2FGAzd1bfVXkBTszqB8PZuuQEs5ObBfWjGbJGKhY8KuFgcR7B61hamzfhokCMGcxOMJP6YY9ZWqU4ba9WT04ZU53pgEJmUTuRCKtVqVL%2FgT1GlzlKQJN80gZ1Wb9t13yVRva%2FTRn%2FOXzfBhPIrxJv0KfXLUx8qHDweBwo5U2r8CG0N4xW5GJTgs2ncDBNXjWSjLE3dhG9G1louVP3ydryCQ%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1661496711", oauth_version="1.0"
Content-Length: 312
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&card_recurring_payment_id=1491830
&client_orderid=1
&currency=USD
&cvv2=123
&deposit2card=false
&destination_card_recurring_payment_id=1491829
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&redirect_url=http%3A%2F%2Fwww.example.com
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Fri, 26 Aug 2022 06:52:10 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddafbb
&merchant-order-id=1
&paynet-order-id=6863044
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 12:38:47 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [317a3dcd-a96e-4b3a-801c-c5cfe7d05dad]
```

##### Transfer from Deposit to PAN

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="Fw1O8eTrqovCuHhmHJ35utckB11MkfwD", oauth_signature="DRmRSQPQPw%2BkDcpNiOboL98MDQzvH73OfM%2F0ylUFoUbm165GsbkhT0TJhFD%2BjpSLiEXnzinRaiDtTc%2FoEDLVuCf7EjNfIsKT6xLEkp39xf08yrr2QWeqeAu6mpmwzq7%2BVNVobo0UCzQXMCZbkZOh%2B4US2pbJbZ0QrZFwGo%2Fd73weyecFBe4Z3ua4Q94MvMUKioH%2FD%2FvjFvlB6Mf8ua6b3%2Fmo5%2BiRwXykic1mWUBf7TB6MXgpRcu9eET3BbGc8%2FS0Xn9Lv2KE%2FoUYN4SmE%2BWgZXE3WR5DALkVrKYzXO5pOguqsy3IAp%2Blu%2F1XaU%2BxqxclAF%2B4KBGlrQt2RINSe%2FgCHTh9qwTiNJcCURdVZ%2Bid6jqGWo4IswEwRgCAHvOXbsoZTj2qW6YqpCm7U1v58FSbLhMlQy%2Fp6cpArnLGU1KDRjVo4nzFnsgIJaPw1im2PuM13X1ueaPsb7wEPWdJbpzs5cLViI7pkPSXSVWCApRsCRu%2B25%2FzSqrz%2FPwO4%2F3dhbkP9CDw9BMOAtonBJzHJtFDKsM2x0U56qv1xaJgEYGUVaOwyy%2FZnOrde4kPX2tkaBF6fFzZkoaMLI1CqBWbQHvWTXZ1vgWe6NIQmFve9NPjA69%2FEhTO2SREA8R2GkSOhF1UBtc1cRg8z6dY4jXbqr7UfwSsu%2BI3JB7%2BDTlMEOVSpfTEA8pbuqHwQL9YGV2BYPUTkVTMIfuetz2byaNafv9TsdV1QBi5uqbjT%2FTXeZ3214zL7rIU1UpqAHXkAcEraZDQV3h5X0i37yTmCOvMkfBl%2B0DnhZbSHkgCLd5aqDc4Hm0pvTfDFa92PcqAqOrK4TMERKQUkjMJFucoWP3fjRS7dQFsBLpWTbtKoNkycALHtd%2BI0PIzglrpJoO9AoHMbQJGZd4OXouBnkjo0KjjJqP4ZRGdtfMH4ADSj%2FyC1w0OaWcZGNkNEABS%2BRVpGD9VCOrYoe695Xt9XV4UEGygCReJ92WqhbnqafrGVu6eXCeIuV7KaUH7aLps5YzIySpDeJLKQTU5J7TuCZfOniLh5C2to%2Bl0h0BnqHX5FsU6RzQnPF9QkU0i1A2K%2B1nfqYOHUFq8wJNo4BIQwosUo7FzYRVzgSXqMnF5gQ7NYMkwxCaUz96XNTDj1vlzQWSyo3AgS6Jb5oIy5yr%2B%2FJPdzEcHf37Ot7kUAtmE3fLZrH%2BcrUd2jZ7tRHxcndQiTodbT0pjhT2qv4WcbXqPaWIWURBB8OxdH7QELxPyG%2BUUvPaiUGscDZ76aJnEk%2BT5jBC2Hak8%2B9Zy4qB%2Ft2QCTPwoAkuC2oHUafzaA8JzytjJLVQpTFvLh7Lj%2BAWg7KZGqKfYX1tmDsYUrdBRb9PfgmCPZ6owEkbDPQ%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1662384499", oauth_version="1.0"
Content-Length: 197
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&client_orderid=1
&currency=USD
&deposit2card=true
&destination-card-no=4402746838361941
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 05 Sep 2022 13:28:35 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddb02e
&merchant-order-id=1
&paynet-order-id=6863078
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 12:58:56 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [3fc83866-7aac-4c92-b6e9-828069e5a9d2]
```

##### Transfer from Deposit to RPI

**Request Example**

```http
POST /paynet/api/v4/transfer/39509 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth oauth_consumer_key="TestMerchant", oauth_nonce="F2ab2fvpltW1oWmn7xV1coohcnHXAROc", oauth_signature="V5ufFoDRY%2BMR8pUP6PgCOHg2M8t53EepdzSvqzzMdQVQ3oEoyPW0TPQK1daviExQ%2FF%2Ft1Lc77n1RKopD0SXbM2UBXe%2FE9RNDERHO4blb01bKCTm9N2IAUTW5PWKcreOLYuiCt2nh5cwY2hFbvxFl5EPoUk06AIoA9wFmrNEICBQJtDhtj7bULmAZhqoXgifgPEcNsfsNDZlk4mQLRhjsONbehon7GlsU8u0itV9I0S0qZnld4zfX5UOORi3xpMEnUfn4DVuLEgElIGeOJ1Th8r3LuO53QYOcmpyJ28Es%2FXDLZh0%2Fg2jJ8kaamcL3EMewZcIwyB1FOiKUBniwX%2BXattNeXbniXTBqPG%2B653RpqEMG3YwAIbAobxLk%2B2q6plW5EDApY8rXXv61WBzVJ2pfBakWHUGslBl5SynzzhE14EFDT6eL4dl22qm%2FM6i7fJGea2d5zFboVgZ0uIXChOgtoN8gJa3mMHt2isfRzuCg8K22hkgNy3CMYeUh7TFYxgsAr14pBXKjMS6MgMvXnPsxWoMlTF4dE9xQRY7nS42K%2FcrECPfnIcjK8HvT%2Bsux4ytps%2BKrBBfXnq%2Bjg%2BtT7LjR1mQnvaWw5HRMDlz1C%2BsmO4J%2BLJQBmpKknFNBv3oxGejhzZTtVcEGddCMNeh4KXUCMucJdb1I8ssq03yFS%2FPrDZbbdK%2Fy7VonLxWg0jozw6l46M9YLvJE9clUBvhgpuG6ClMecpgoQvDMnR%2BIx3zl1qy6E8eDyaXJ%2Bh4opohJrSRGDiTcVtGRbcZUr%2FWyLDUR625LjavHv9zT1aGGieSTsNM%2BeLgxkSzRlyXR4E4zjqDAB3J9rwKKbZyx8gTduMhGydUGDapNwKVhC5hb0F%2ByYjwiz2MO5Qr40mdeBfejdAJx4%2ButBszx0lOuczlIjR8L8NAn5LVrmuf33nLT63J8mTgXU%2F1bnQQHvmnTA4nX2NkpXbUDHfry8H%2FOoyCbs6dChX4RrJOQkS49tjxzJuiFIxAsUHkrlxdS9cHuluG5%2FV%2Fp6IwYHcWhUG2PxW6PJAcuin32sM66p%2Ff63CAcu46V9cIyoXpeSBvYZMZ8jt6Guowy5uHDImUFli%2FHCVopWLs%2FRFyY2iJUmqKypGh7Po%2FJyVhAYdpXrpaLTEmOd4OpLUO0GaxjaPTmcKuDGmXDQEFmC00zAT6%2F57tvZ38bhqSbReM5dWZC6mog9iC2wjY4gpDf%2FUTX7gPGmQkefTysz84QdRdoDNi0BDDfBD5lOPSpZmMs67obwXgnsrJOdlGNRyEjQ%2B8hZgxXH2mWh2wX4skHq43kxaJJ2bdIVab9BNtVj5YjnUJxJWJoe0a0%2B7slFQwfxIm8lxKwtJdEgK6r01UOLg%3D%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1662384669", oauth_version="1.0"
Content-Length: 206
Content-Type: application/x-www-form-urlencoded
Connection: close

amount=10.42
&client_orderid=1
&currency=USD
&deposit2card=true
&destination_card_recurring_payment_id=1491830
&ipaddress=1.1.1.1
&order_desc=Your%20order%20description
&server_callback_url=https://httpstat.us/200
```

**Success Response Example**

```http
HTTP/1.1 200 OK
Server: server
Date: Mon, 05 Sep 2022 13:31:42 GMT
Content-Type: text/html;charset=utf-8
Connection: close
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 137

type=async-response
&serial-number=00000000-0000-0000-0000-000002ddb02f
&merchant-order-id=1
&paynet-order-id=6863079
&end-point-id=39509
```

**Fail Response Example**

```http
HTTP/1.1 500 Internal Server Error
Server: server
Date: Fri, 14 Oct 2022 12:55:09 GMT
Content-Length: 61
Connection: close
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [51a48bc5-a061-40c5-b88b-f2c084024b77]
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/transfer/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/update-recurring-payment

#### Introduction

/api/v4/update-recurring-payment is a synchronous API command. If request is accepted with no errors, the Payment Gateway finds the recurring payment profile by the provided recurring-payment-id and updates this profile. The recurring transactions will be processed according to the updated recurring payment profile using the payment data saved in this profile.
 
Update recurring payment is initiated through HTTPS POST request by using [URLs](#api-v4-update-recurring-payment-request-url) and the [parameters](#api-v4-update-recurring-payment-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------------------|------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/update-recurring-payment/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/update-recurring-payment/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

> **Note:** The RPI details screen (recurring payment profile) contains information about linked cardholder and customer data, recurring schedule and processed transactions with this RPI. This screen also contains change history for this RPI. The change history is currently available for source cards (SRC) only.

Type native on UI means that The recurring payment setup and the actual charges are in the same acquirer.
 
If the recurrent has switched to Stopped, you can update its schedule using the start-date and finish-date parameters. However, it can only be resumed via the UI by clicking on Resume.
 
To stop the automatic recurring schedule, use [Request Parameters](#api-v4-update-recurring-payment-request-parameters). Available only for SRC.
 

| Parameter Name | Description | Value |
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| client-orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| recurring-payment-id | Recurring ID assigned to the order by QA. | `Necessity`: Required `Type`: String `Length`: 128 |
| credit-card-number | Payer’s credit card number. card-printed-name can only be specified when card number is specified. | `Necessity`: Conditional `Type`: Numeric `Length`: 19 |
| card-printed-name | Payer\`s card printed name. Required when card number is specified. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| expire-year | Payer\`s card expire year. Can only be specified when card number is specified. Required when card number is specified. | `Necessity`: Conditional `Type`: Numeric `Length`: 4 |
| expire-month | Payer\`s card expire month. Can only be specified when card number is specified. Required when card number is specified. | `Necessity`: Conditional `Type`: Numeric `Length`: 2 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-from | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-to | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-sequence | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0. Supported for SRC and DST type. Required if amount-from and amount-to or amount are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| period | Possible values are: day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| interval | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: Int `Length`: - |
| customer-ip | Payer\`s IP address. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 45 |
| country | Payer\`s country. | `Necessity`: Optional `Type`: String `Length`: 2 |
| city | Payer\`s city. | `Necessity`: Optional `Type`: String `Length`: 128 |
| address1 | Payer\`s address. | `Necessity`: Optional `Type`: String `Length`: 256 |
| first-name | Payer\`s first-name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| last-name | Payer\`s last-name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| order_desc | Description of Recurring payment. | `Necessity`: Optional `Type`: String `Length`: 65K |
| zip-code | Payer\`s zip-code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| birthday | Payer\`s birthday date. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| email | Payer\`s email. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ssn | Social security number field. | `Necessity`: Optional `Type`: String `Length`: 32 |
| phone | Payer’s full international phone number, including country code. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| start-date | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| finish-date | Date, when the Payer will be charged last time. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| max-repeats-number | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made (unless done manually), even if a recurring payment is stopped and rescheduled again. | `Necessity`: Optional `Type`: Int `Length`: - |
| purpose | Purpose of transaction. | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | Notify url field. server_callback_url parameter can also be used. For more information please see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | Connecting Party URL which will receive callback request once the transaction reaches final status. Connecting Party may use Server Callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. See callback details in [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Send either notify_url or server_callback_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

> **Warning:** /api/v4/create-recurring-payment is a synchronous API command. The response will be returned after the recurring payment profile will be created on Payment Gateway side.

| Response Parameters | Description |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. Example: update-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| status | If request is accepted, this parameter has approved value. This is not a transaction status. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| error-message | If status is declined or error this parameter contains the reason for decline or error details. |
| error-code | The error code in case of declined or error status. |

#### Request Example

```http
POST /paynet/api/v4/update-recurring-payment/ HTTP/1.1
User-Agent: curl/8.4.0
Accept: */*
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant", oauth_nonce="XBhUVJU4N8fBnNRGfY91Z3wuZ6iNgjVM", oauth_signature="RIRufAZeoBZBMpVlr7Bt%2Bc6fDTUxZJgxjJUlTo7Pm9zlGeZAl427VF6c%2B0lkGvZfATlooYBK%2FeoZaUU5gJITePycMmZr2gPzAk8xCielclB8N0j5Rp3ga0A%2B3uJDTgQdvsrosYK4tsES%2BPsR6qjhf%2FqWGHbpwCooXbMLwI9a9yMdkwmcRNQGPWAz7I%2FJ8gdDLvkjM0H8fZRp%2Bz%2FSAd3%2FgX%2F%2BCJv7bMn26hOGUxJua7u5GIKX6mmZ5FpV71xdy04ebPu4qAXGPGNKBZXLJGqzYfYVlW9XWKKkFhUA4RLYUZqnfokHA8uy3zb8IY8tKZOjXxmytlFKdVr%2BYAiHxlMt%2BEq%2BlovLAXWENbIXvJYhRiX%2F3QO2cq2ZznAsanZQiyU7AT3O9lnLHuvKc2wbuFKr277lNR24cykI3ja%2FGMR%2F8T%2BXjZKFF%2F1sYVRGd93CQDx6NHnH98vp%2Bv3PMopOmLWwggyOApmDBDsa8jYoU1TDOs6gNRTsXIyFiSwl3e48fNAp%2FjFZfUl90K8wGusNzrof05UdTPR%2B7zpv4jL1hd1XyN%2F4x7aNNQ28tm5LSoVU6t%2BQkvwRm%2FNxnDKMYEE9rq7s4Uq5KTzAmM89pAu52WFbDQXYoZgy3vm%2B0SsJDXH0IVXsDpLDt1zcJClWoeXxT0fqOcEojJhuosvbcI%2FIaEpxWH8%3D", oauth_signature_method="RSA-SHA256", oauth_timestamp="1721312815", oauth_version="1.0"
Content-Length: 624
Content-Type: application/x-www-form-urlencoded
Connection: keep-alive

address1=1234%20Peace%20street
&amount=55
&birthday=1980-01-02
&card-printed-name=JOHN%20SMITH
&recurring-payment-id=1492124
&city=Chicago
&client-orderid=1575634981130
&country=US
&credit-card-number=4464920026265488
&currency=USD
&customer-ip=1.2.3.4
&email=john.smith%40example.com
&expire-month=12
&expire-year=2040
&finish-date=2040-01-01
&first-name=John
&interval=1
&last-name=Smith
&max-repeats-number=1000
&notify-url=http%3A%2F%2Fexample.com%2Fnotify-me
&order_desc=testing%20purposes
&period=week
&phone=12345678
&purpose=No%20purpose%20at%20all
&ssn=1234
&start-date=2030-01-01
&state=IL
&zip-code=123456
&server_callback_url=https://httpstat.us/200
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 18 Jul 2024 14:27:39 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
Content-Language: en-US
Strict-Transport-Security: max-age=31536000
Content-Length: 107

type=update-recurring-payment-response
&serial-number=00000000-0000-0000-0000-000002f36d82
&status=approved
```

#### Fail Response Example

```http
HTTP/1.1 500
Server: server
Date: Thu, 18 Jul 2024 14:41:27 GMT
Content-Length: 61
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000

Internal server error [00b20f25-2933-48e3-973b-0664114b8492]
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/v4/update-recurring-payment/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/v4/update-recurring-payments

#### Introduction

If request is accepted with no errors, the Payment Gateway finds the recurring payment profile for each provided recurring-payment-id and updates these profiles. The recurring transactions will be processed according to the updated recurring payment profiles using the payment data saved in each profile.
 
Update recurring payment Multiple is initiated through HTTPS POST request by using [URLs](#api-v4-update-recurring-payments-request-url) and the [parameters](#api-v4-update-recurring-payments-request-parameters) specified below. Use [OAuth RSA-SHA256](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------------|-------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v4/update-recurring-payments/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/v4/update-recurring-payments/ENDPOINTID |

#### Request Parameters

> **Note:** Request must have content-type=application/x-www-form-urlencoded and [Authorization headers](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md).

Below is a description of each parameter that can be included in the CSV and added to payload parameter which will be used in the request.
 
Any changes to recurring payment profile made with Update command can be viewed only via UI.
 

> **Note:** The RPI details screen (recurring payment profile) contains information about linked cardholder and customer data, recurring schedule and processed transactions with this RPI. This screen also contains change history for this RPI. The change history is currently available for source cards (SRC) only.

Type native on UI means that The recurring payment setup and the actual charges are in the same acquirer.
 
If the recurrent has switched to Stopped, you can update its schedule using the start-date and finish-date parameters. However, it can only be resumed via the UI by clicking on Resume.
 
To stop the automatic recurring schedule, use finish-date in the past in [Request Parameters](#api-v4-update-recurring-payments-request-parameters).
 

| CSV Parameter Name | Description | Value |
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| client-orderid | Connecting Party order ID. | `Necessity`: Required `Type`: String `Length`: 128 |
| recurring-payment-id | Recurring ID assigned to the order by QA. | `Necessity`: Required `Type`: String `Length`: 128 |
| credit-card-number | Payer\`s credit card number. | `Necessity`: Required `Type`: Numeric `Length`: 19 |
| card-printed-name | Payer\`s card printed name. | `Necessity`: Required `Type`: String `Length`: 128 |
| expire-year | Payer\`s card expire year. | `Necessity`: Required `Type`: Numeric `Length`: 4 |
| expire-month | Payer\`s card expire month. | `Necessity`: Required `Type`: Numeric `Length`: 2 |
| amount | Amount of currency must be the same as currency on the project assigned. Upon reaching finish date, Recurring payment will go into stop status. Supported for SRC and DST type. Required if amount-from and amount-to or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-from | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-to | If the combination of amount-from and amount-to is chosen, every charge will be of random amount between these two numbers. Supported for SRC and DST type. Required if amount or amount-sequence are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| amount-sequence | If amount sequence is chosen, client will be charged amounts from this list. Example of setting up amount sequence: 10.5, 24.6, 32.0. If repeats number is higher than amount sequence number of elements, every new charge will be with last amount in amount sequence. In order for charges to begin from the first amount in the chain, current repeats number must be set as 0. Supported for SRC and DST type. Required if amount-from and amount-to or amount are not used. | `Necessity`: Conditional `Type`: Numeric `Length`: 10 |
| period | Possible values are: day, week and month. In case if daily is chosen, client will be charged every day. If week - every 7 days. If monthly is chosen, client will be charged on the same date of the month, from the starting date, no matter how many days there are in a month. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: String `Length`: 32 |
| interval | Interval is a multiplier applied to the period. For example, if interval of 2 and period ‘Daily’ is selected, client will be charged once every 2 days. Interval and period can only be specified or omitted together. Not supported for DST. | `Necessity`: Conditional `Type`: Int `Length`: - |
| country | Payer\`s country. | `Necessity`: Optional `Type`: String `Length`: 2 |
| city | Payer\`s city. | `Necessity`: Optional `Type`: String `Length`: 128 |
| address1 | Payer\`s address. | `Necessity`: Optional `Type`: String `Length`: 256 |
| first-name | Payer\`s first-name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| last-name | Payer\`s last-name. | `Necessity`: Optional `Type`: String `Length`: 128 |
| customer-ip | Payer\`s IP address. Supported for SRC and DST type. | `Necessity`: Optional `Type`: String `Length`: 45 |
| order_desc | Description of Recurring payment. | `Necessity`: Optional `Type`: String `Length`: 65K |
| zip-code | Payer\`s zip-code. | `Necessity`: Optional `Type`: String `Length`: 10 |
| birthday | Payer\`s birthday date. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| email | Payer\`s email. | `Necessity`: Optional `Type`: String `Length`: 128 |
| ssn | Social security number field. | `Necessity`: Optional `Type`: String `Length`: 32 |
| phone | Payer’s full international phone number, including country code. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 128 |
| state | Payer’s state. Please see [Mandatory State codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Required for USA, Canada and Australia. Not supported for DST. | `Necessity`: Optional `Type`: String `Length`: 2-3 |
| start-date | Date, when first charge is scheduled. If start date is set as a current date and type is set as auto, first charge will be made today. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| finish-date | Date, when the Payer will be charged last time. | `Necessity`: Optional `Type`: 8/Numeric, DD.MM.YYYY `Length`: 8 |
| max-repeats-number | Index of recurring transaction, first charge will hold the index of 0. Current repeats number increases even if a charge was unsuccessful. When current repeats number reaches max repeats number, Recurring payment goes into stop status and client is charged no more. If a charge was made automatically, no additional charges will be made (unless done manually), even if a recurring payment is stopped and rescheduled again. | `Necessity`: Optional `Type`: Int `Length`: - |
| purpose | Purpose of transaction. | `Necessity`: Optional `Type`: String `Length`: 128 |
| notify_url | Notify url field. server_callback_url parameter can also be used. For more information please see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). | `Necessity`: Optional `Type`: String `Length`: 1024 |
| server_callback_url | Connecting Party URL which will receive callback request once the transaction reaches final status. Connecting Party may use Server Callback URL for custom processing of the transaction completion, e.g. to collect payment data in the Connecting Party’s information system. See callback details in [Connecting Party callback parameters](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md). Send either notify_url or server_callback_url, not both. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Response Parameters

> **Note:** Response has Content-Type: text/html;charset=utf-8 header. All fields are x-www-form-urlencoded, with (0xA) character at the end of each parameter’s value.

| Response Parameters | Description |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. Example: update-recurring-payment-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. Multiple error codes may be received: 200, 403, and 500. For the 500 error code, an additional error ID will be returned. |
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant |

#### Request Example

**Step 1.** Create a CSV with the provided structure:
 
```http
"client-orderid";"recurring-payment-id";"payment-description";"first-name";"last-name";"address1";"city";"zip-code";
"country";"state";"phone";"email";"customer-ip";"period";"interval";"start-date";"finish-date";"max-repeats-number";"amount";
"amount-from";"amount-to";"amount-sequence";"currency";"card-printed-name";"credit-card-number";"expire-month";"expire-year"
```

**Step 2.** Encode CSV to base64 with the following command:
 
```bash
base64 update-recurring-payments-example.csv
```

**Step 3**. Assign the base64 encoded value to payload parameter and send the request:
 
```http
POST /paynet/api/v4/update-recurring-payments/ HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/8.4.0
Accept: */*
Content-Type: application/x-www-form-urlencoded
Authorization: OAuth oauth_consumer_key="ErwinTestMerchant",oauth_signature_method="RSA-SHA256",oauth_timestamp="1727177782",oauth_nonce="Js4dwXkF8eI",oauth_version="1.0",oauth_signature="VwdA7BQ68v%2BmpB0N%2BUOxK%2BxYk355i1QzeUPGGGFwDEBn7Y8v1xpSolGQ45HehGmJHNjXHc7A1mP3x7V7r2pQju1LpDEvAb2MHNLSCHiCEjI95sCtrotE%2Fs5%2FmQmIJ8te%2FGFCR1uK%2BzMPG8bpHqn%2B5EIEsuLPq6TSOjD0N3RvnV%2BHdmjH5cxTcmtRrcY0u6VIpvkBUlqpKuTVJXLvbpxRexvgPMDow78QS3DLRQhi6G7Y%2FVshKpKC%2FSRThhe8L33tFckX6KaEbJ3XIMEmP7O%2F%2FQdLfWQBn4ldSp8K8lpkgZks4CZbAjDY%2BQpSfwdc1s8kJf17Ymk1R69aGBmjzJrw00tV4dzY4DE6XVqSTUR8X%2FCa0XMrtD46ichsFoRvFtIeyV%2FIud%2F%2FLSb8XDqk%2BaftSLazBokmT8Qe1FMf0UMgUYBLCl0B4O66Ys8kH4Z6guC2MXarwu%2BDlfuelrcAHevS68hewrMb%2FjppSJWAbQiBOABeW6s1Rb4dvbJnZribkKhEwrxmnT5drsTYvukC2UCoUblEOgVkFHdHk5E3OqT4wMxqXojlYr5Il7m1GkHVYELb964ukROLkohGoTjYEKj%2FUHirjybDWeynTCSaGe%2Bv3JtEbkydWXannkdtTvk0xkbT6LurBiNWy1FuSTmKod9ibqyNiEv6j%2Be14BBGXs3xc5A%3D"
Content-Length: 888
Connection: keep-alive

payload=cmVjdXJyaW5nLXBheW1lbnQtaWQ7dHlwZTtjbGllbnQtb3JkZXJpZDtwYXltZW50LWRlc2NyaXB0aW9uO2ZpcnN0LW5hbWU7bGFzdC1uYW1lO2FkZHJlc3MxO2NpdHk7emlwLWNvZGU7Y291bnRyeTtzdGF0ZTtwaG9uZTtlbWFpbDtjdXN0b21lci1pcDtwZXJpb2Q7aW50ZXJ2YWw7c3RhcnQtZGF0ZTtmaW5pc2gtZGF0ZTtjdXJyZW50LXJlcGVhdHMtbnVtYmVyO21heC1yZXBlYXRzLW51bWJlcjthbW91bnQ7YW1vdW50LWZyb207YW1vdW50LXRvO2Ftb3VudC1zZXF1ZW5jZTtjdXJyZW5jeTtjYXJkLXByaW50ZWQtbmFtZTtjcmVkaXQtY2FyZC1udW1iZXI7ZXhwaXJlLW1vbnRoO2V4cGlyZS15ZWFyO2N2djI7cHVycG9zZTtub3RpZnktdXJsO3NzbjtiaXJ0aGRheQ0KMTQ5MjI4NjttYW51YWw7MTIzNDU2Nzg5MDtPdXIgc3VwZXIgZ29vZHM7Sm9objtTbWl0aDsxMjM0IFBlYWNlIHN0cmVldDtDaGljYWdvOzEyMzQ1NjtVUztJTDsxMjM0NTY3ODtqb2huLnNtaXRoQGV4YW1wbGUuY29tOzEuMi4zLjQ7d2VlazsxOzAxLjAxLjIwMzA7MDEuMDEuMjA0MDswOzEwMDA7MTA7Ozs7VVNEO0pPSE4gU01JVEg7NDUzODA5NjQxNTA4NDc1NjsxMjsyMDIwOzEyMztObyBwdXJwb3NlIGF0IGFsbDtodHRwOi8vZXhhbXBsZS5jb20vbm90aWZ5LW1lOzEyMzQ7MDIuMDEuMTk4MA0K
```

#### Success Response Example

> **Note:** The successful response has empty body and HTTP code 200.

```http
HTTP/1.1 200
Server: server
Date: Tue, 24 Sep 2024 11:40:45 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
```

#### Fail Response Example

> **Note:** The unsuccessful response has empty body and HTTP code 403.

```http
HTTP/1.1 403
Server: server
Date: Wed, 25 Sep 2024 08:47:54 GMT
Content-Length: 0
Connection: keep-alive
Keep-Alive: timeout=60
X-XSS-Protection: 1
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000
```

### Verification card mapping notification

#### Introduction

Verification card mapping notification is initiated through HTTPS POST request by using [URLs](#api-url-verification-card-mapping-notification) and the [parameters](#api-parameters-verification-card-mapping-notification).
 
Card mapping notification is used to allow Consumer credentials (phone, email, billing address, twitter name, etc) for mapping to card data. Card mappings can be used later in transfer or sale transactions instead of card numbers and other cardholder information. Payneteasy sends Verification card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}.
 
Connecting Party’s server maps this {server Card Id} to {client Card Id}, created on its side. This {client Card Id} can then be mapped in Connecting Party’s app or on Connecting Party’s server to any Consumer’s data from the initial Perform validation request. This allows Connecting Party’s app to process sale or transfer transactions by Consumer’s email, phone number, etc.
 
{unique Reference Card Id} remains the same if Consumer makes another verification with the same card number but different expiry date, for example. It can be used by Connecting Party for loyalty programs or fraud control.
 

#### API URLs

> **Note:** This is an example of URL format on Connecting Party server.

| Connecting Party Server |
|-------------------------------------------------------------------|
| https://proxy.connectingpartyserver.com/verification/notification |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------------------|-------------------------------------------------|---------------------------------------------------------|
| consumer | | `Type`: **Object** |
| consumer.device | | `Type`: **Object** |
| consumer.device.serial Number | Consumer’s device serial number. | `Type`: String `Length`: 1-50 |
| reference | | `Type`: **Object** |
| reference.server Card Id | The card reference identifier (on server side). | `Type`: String `Length`: 1-64 |
| reference.unique Reference Card Id | The card identifier (on server side). | `Type`: Integer |
| session | | `Type`: **Object** |
| session.access Token | Consumer’s access token key. | `Type`: String `Length`: 32-128 |
| session.token | The session token of verification transaction. | `Type`: String `Length`: 16-36 |
| source Card | | `Type`: **Object** |
| source Card.bin | The Source card BIN. | `Type`: Integer |

#### Success Response Parameters

| Parameter Name | Description | Value |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| invoice Id | Verification transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.check Signature | Checksum generated by hmac-sha1 (see [Signature computation](https://doc.payneteasy.com/integration/api_development_tools.html.md)) from the concatenation of the session.nonce, the endpoint Id and the invoice Id. | `Type`: String |
| session.nonce | Unique random string generated by Connecting Party’s server. | `Type`: String |
| session.token | The session token of verification transaction. | `Type`: String |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `SERVER_FAILED`, `SERVER_UNAVAILABLE`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Verification transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "consumer": {
    "device": {
      "serialNumber": "string"
    }
  },
  "reference": {
    "serverCardId": "string",
    "uniqueReferenceCardId": "integer"
  },
  "sourceCard": {
    "bin": "integer"
  },
  "session": {
    "accessToken": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "invoiceId": "string",
  "session": {
    "checkSignature": "string",
    "nonce": "string",
    "token": "string"
  }
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Verification status

#### Introduction

Verification status is initiated through HTTPS POST request by using [URLs](#api-url-verification-status) and the [parameters](#api-parameters-verification-status).
 
 
Verification status request is made by Connecting Party’s app to Payneteasy to get the status of verification transaction.
 
It is recommended to send Verification status request for a period of 2-3 minutes with interval of 3-5 seconds between requests.
 
Connecting Party’s server should rely on the callback for final status.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/dapi/v1/verification/{endpoint Id}/{invoice Id}/status | https://gate.payneteasy.eu/paynet/dapi/v1/verification/{endpoint Id}/{invoice Id}/status |

#### Request Parameters

| Parameter Name | Description | Value |
|---------------------|--------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| session | | `Necessity`: Required `Type`: **Object** |
| session.access Token | The access token key received in Optional consumer authentication. | `Necessity`: Required `Type`: String `Length`: 32-128 |
| session.token | The session token of verification transaction. | `Necessity`: Required `Type`: String `Length`: 16-36 |

#### Success Response Parameters

| Parameter Name | Description | Value |
|---------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
| invoice Id | Verification transaction identifier. | `Type`: String |
| session | | `Type`: **Object** |
| session.token | The session token of verification transaction. | `Type`: String |
| state | Possible values: `PROCESSING`, `REDIRECT_REQUEST`, `APPROVED`, `DECLINED`. | `Type`: Enum |
| bank Order Id | Required if state is `APPROVED` or `DECLINED`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| redirect Url | Required if state is `REDIRECT_REQUEST`. | `Necessity`: Conditional `Type`: String `Length`: 128 |
| error Code | Decline reason code, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: Integer `Length`: 128 |
| error Message | Decline reason message, may present if state is `DECLINED`. | `Necessity`: Optional `Type`: String `Length`: 128 |
| secure3DAuth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`, `UNSUPPORTED`, `UNSUPPORTED` means that card does not support 3-D Secure or 3DS authentication process finished with an unknown status. | `Necessity`: Optional `Type`: Enum |
| random Sum Auth Status | Possible values: `AUTHENTICATED`, `NOT_AUTHENTICATED`. | `Necessity`: Optional `Type`: Enum |

#### Fail Response Parameters

| Parameter Name | Description | Value |
|------------------|-------------------------------------------------------------------------------------------------------------------------------|------------------------------|
| error | | `Type`: **Object** |
| error.cause | Cause of the error. Possible values: `FILTERED`, `INVALID_REQUEST`, `INTERNAL_ERROR`, `PROCESSING_FAILED`, `ORDER_NOT_FOUND`. | `Type`: Enum |
| error.code | The unique error code. | `Type`: String |
| error.message | Description of the error. | `Type`: String |
| invoice Id | Verification transaction identifier. | `Type`: String |

#### Request Example

```json
{
  "session": {
    "accessToken": "string",
    "token": "string"
  }
}
```

#### Success Response Example

```json
{
  "bankOrderId": "string",
  "invoiceId": "string",
  "redirectUrl": "string",
  "session": {
    "token": "string"
  },
  "state": "enum"
}
```

#### Fail Response Example

```json
{
  "error": {
    "cause": "enum",
    "code": "string",
    "message": "string"
  },
  "invoiceId": "string"
}
```

### Apple Pay Web

#### Introduction

Apple Pay is an electronic wallet system that allows Payer to make one-click payment using a card token issued together with Apple and Issuer bank. There is no need to enter card details during Apple Pay transaction. Access to this payment mechanism is possible from any device, which supports Apple Pay. After choosing Apple Pay payment method, the payer will see the form on which he confirms his Apple account and card he is going to use to pay for order. If payer doesn’t have a previously registered card, he may do it while making payment.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
If accepting payments occurs on the Payneteasy payment page, no additional integration with Apple is required from the Connecting Party.
 
To use Apple Pay on the Payneteasy payment page, do the following:
 
1. Enable Apple Pay on the payment page template by adding macro.
2. Inform Payneteasy support about the need to connect Apple Pay and send updated templates.

The Apple Pay button will automatically appear on the Payneteasy checkout page if:
 
1. The payer uses the Safari browser on a device that supports Apple Pay.
2. The payer has Apple Pay cards available for payment.

> **Note:** It might be necessary for Connecting Party to register [Merchant ID](#register-merchant-id), issue [Payment Processing Certificate](#accountsetup) and [Merchant Identity Certificate](#detailed-instructions-for-domain-verification-and-payment-processing-certificate-registration) in Apple in order to launch Apple Pay. For details please contact Payneteasy support manager.

#### Apple Pay Flow

```plantuml
participant Payer as C
participant "Connecting Party" as cp
autonumber
C -> cp: Checkout
activate cp
alt sale/preauth
cp -> "Payneteasy": sale-form/ENDPOINTID
activate "Payneteasy"
cp -> "Payneteasy": preauth-form/ENDPOINTID
end
"Payneteasy" --> cp: status=processing\nredirect-url
deactivate "Payneteasy"
cp --> C: Provide **redirect-url** to payer's browser
deactivate cp
activate C
loop
cp -> "Payneteasy": Request /api/v2/status
activate cp
activate "Payneteasy"
"Payneteasy" --> cp: status=processing
deactivate cp
deactivate "Payneteasy"
end
C -> "Apple Pay": Check if Apple Pay is supported on Payer's device
activate "Apple Pay"
"Apple Pay" --> C: Apple Pay response
deactivate "Apple Pay"
C -> C: Display Apple Pay button
C -> "Apple Pay": Provide Apple payment data for processing
deactivate C
activate "Apple Pay"
"Apple Pay" --> "Payneteasy": Processing with Apple Pay payment data
deactivate "Apple Pay"
activate "Payneteasy"
"Payneteasy" -> "Payneteasy":  Process payment
"Payneteasy" --> C: Redirect to **redirect_url**
activate C
C -> cp: Return to the Shop
deactivate C
activate cp
group Get Final Status
== Receive Connecting Party Callback ==
cp <- "Payneteasy" : callback with final status
"Payneteasy" <-- cp: HTTP 200
deactivate "Payneteasy"
== Order Status request ==
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> cp : Response\nstatus,order-stage
deactivate "Payneteasy"
end
cp --> C: Show result
deactivate cp
```

(2) To implement sale-form payment request see [/api/v2/sale-form](https://doc.payneteasy.com/integration/API_commands/api_v2_sale-form.html.md).
 
(3) Instead of sale-form it is possible to implement preauth-form payment request, see [/api/v2/preauth-form](https://doc.payneteasy.com/integration/API_commands/api_v2_preauth-form.html.md). Preauth allows to hold the specified amount in the Payer’s card account for a limited time. Preauth can be followed by [Capture](#capture-form-request-url-apple) or [Cancel](#cancel-form-request-url-apple).
 
(14) Payer is returned to Connecting Party site. To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(16) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(18) To implement order status request see [/api/v2/status](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### Capture Flow

Capture is a transaction followed after preauth which deducts the locked amount from Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payneteasy" as B
hnote over A,B : Successful Preauth Transaction
autonumber
group Optional
Payer -> A: Initiate Capture
activate A
end
== Capture ==
A -> B: api/v2/capture
activate B
B --> A: Order ID
B -> B: Process Capture
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate A
end
```

(1) Capture can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

#### Cancel Flow

Cancel is opposite of Capture which cancels the deduction and returns locked by Preauth amount back to Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payneteasy" as B
hnote over A,B : Successful Preauth Transaction
autonumber
group Optional
Payer -> A: Initiate Cancel
activate A
end
== Cancel ==
A -> B: api/v2/cancel
activate B
B --> A: Order ID
B -> B: Process Cancel
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate A
end
```

(1) Cancel can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

#### Apple Pay Account Setup

To configure the terminal on the Payment Gateway side, the following data needs to be sent to the Payneteasy support service:
 
* Merchant ID.
* The private key of the Payment Processing Certificate.
* Private key password.

To get the necessary data, the following steps are required:
 
> **Note:** Please note that the Payment Processing Certificate lasts **25 months**. To renew the certificate, see the section “[Reissue of Payment Processing Certificate]()”.

##### Register Merchant ID

Merchant ID - Apple Merchant Site ID (or MID) is a unique identification number that tells the payment processing systems involved in a transaction where to send which funds.
 
 
1. Open developer account. Go to Certificate, Identifiers & Profiles.
2. Go to Identifiers.
3. Click on “+”.
4. Select Merchant IDs.
5. Specify the description and the Merchant ID. It is recommended to use the website domain in reverse order with the Connecting Party’s prefix. Example: connecting party.com. Payneteasy.applepay.test.
6. Click Register.

**Merchant ID** is now registered.

##### Create Certificate Signing Request

Certificate Signing Request is a request to issue a certificate, in our case in order to get Payment Processing Certificate.
 
1. Open Keychain Access on Mac.
2. Certification assistant -> Request a certificate from a Certificate Authority.
3. Specify the email, to which the developer’s account was registered, the name (also key name). Select Saved to disk and Specify information about a pair of keys manually.
4. Select the key size 256 bits and the ECC Algorithm. Click Continue button. Save the .cert Signing Request file.

##### Issue Payment Processing Certificate

1. Return to the developer’s office. Go to Certificates, Identifiers & Profiles / Identifiers. Select needed Merchant ID.
2. Click Create Certificate in Apple Pay Payment Processing Certificate section.
3. Select “No” and click Continue.
4. Choose .cert Signing Request file from step 2 and click Continue.
5. Download **Payment Processing Certificate**.

##### Get the Certificate Private Key and Private Key Password

1. Double click Payment Processing Certificate on Mac to install.
2. Open Keychain Access and go to Certificates section.
3. Find the certificate. Select the created key by clicking on the arrow next to it.
4. Select Export with the right mouse button.
5. Select the folder to save the key file in .p12 format, click Save.
6. Create password and click OK. **Private key** <name>.p12 and **private key password** are ready to work.

##### Reissue of Payment Processing Certificate

The Connecting Party must independently monitor the validity period of the Apple Pay certificate (25 months). Before the certificate expires, a new certificate must be issued.
 
This requires the following:
 
1. Create a new Certificate Signing Request, as described in [step 2](#create-certificate-signing-request).
2. Issue a new Payment Processing Certificate as in [step 3](#issue-payment-processing-certificate). After creating a new certificate for the current Merchant ID, there will be two certificates: **old** (active) and **new** (requiring activation). At this step **there is no need** to activate the new certificate.
3. Get the certificate private key, private key password and send them to Payneteasy support service as in [step 4](#get-the-certificate-private-key-and-private-key-password).
4. Activate a new certificate **only in consultation with Payneteasy support service**. After activation, only the new certificate will be used, the old one will become inactive.

#### Merchant Identity Certificate

The following data needs to be sent to the Payneteasy support service:
 
1. Merchant ID.
2. The private key of the Merchant Identity Certificate.
3. Private key password.

> **Note:** Please note that the validity period of the Merchant Identity Certificate and domain verification is **25 months**. To renew the certificate and re-verify domains, see the section [Re-verification of domains and reissue of the Merchant Identity Certificate](#re-verification).

##### Domain Registration and Verification

> **Warning:** Before receiving the Merchant Identity Certificate, it is compulsory to create and validate domains where Apple Pay will be used.

1. Go to the developer’s office and go to Certificates, Identifiers & Profiles. [Create](#register-merchant-id) a Merchant ID before domain registration.
2. Go to Identifiers.
3. App IDs -> Merchant IDs.
4. Select the needed Merchant ID.
5. Click Add Domain in Merchant Domains.
6. Specify the domain where Apple Pay will be used and click Save.
7. To confirm ownership of a domain, download the file and place ot at the specified address, the file at the specified address must be accessible from outside the Connecting Party’s network.
8. Click Verify to verify the domain.

##### Creation of Merchant Identity Certificate

Step 1. [Create Certificate Signing Request]()
 
Step 2. [Issue Merchant Identity Certificate]()
 
Step 3. [Get the certificate private key and private key password]()
 

##### Create Certificate Signing Request

Certificate Signing Request is a request to issue a certificate, in our case in order to get Payment Processing Certificate.
 
1. Open Keychain Access on Mac.
2. Certification assistant -> Request a certificate from a Certificate Authority.
3. Specify the email, to which the developer’s account was registered, the name (also key name). Select Saved to disk and Specify information about a pair of keys manually.
4. Select the key size 2048 bits and the RSA Algorithm. Click Continue button. Save the .cert Signing Request file.

##### Issue Merchant Identity Certificate

1. Return to the developer’s office. Go to Certificates, Identifiers & Profiles / Identifiers.
2. Go to Identifiers.
3. App IDs -> Merchant IDs.
4. Select the needed Merchant ID.
5. Create Certificate in Apple Pay Merchant Identity Certificate section.
6. Select created in step 1 .cert Signing Request file and click Continue.
7. Download **Merchant Identity Certificate**.

##### Get the Certificate Private Key and Private Key Password

1. Double click Merchant Identity Certificate on Mac to install.
2. Open Keychain Access and go to Certificates section.
3. Find the certificate. Select Export with the right mouse button.
4. Select the folder to save the key file in .p12 format, click Save.
5. Create password and click OK. **Private key** <name>.p12 and **private key password** are ready to work.

##### Domain Re-verification and Merchant Identity Certificate Reissue

The Connecting Party must independently monitor the validity of the certificate and domains’ verification (25 months).
A new Merchant Identity Certificate must be issued before the certificate expires. Certificates can be used concurrently, so the procedure for issuing a new one is as described in the “Creating a Merchant Identity Certificate” section.
Before the expiration of the domain verification period, the Verify button is activated next to it.
The verification procedure corresponds to that described in the section “Domain registration and verification”.

### Async-Response

```plantuml
@startuml
participant cp as "Connecting Party"
participant paynet as "Payneteasy"
==Request Initiation==
cp -> paynet: API Request
activate cp
activate paynet
paynet --> cp: Order ID
deactivate cp
deactivate paynet
==Order Status Request==
cp -> paynet: api/v2/status
activate cp
activate paynet
paynet --> cp: Response\nstatus, order-stage
deactivate cp
deactivate paynet
==Receive Merchant Callback==
paynet -> cp: callback with final status
activate cp
activate paynet
cp --> paynet: HTTP 200
deactivate cp
deactivate paynet
@enduml
```

Unless explicitly stated otherwise in relevant API command, all Payneteasy responses are asynchronous, regardless of the request or callback sent.

### Bank transfer with Invoice

#### Introduction

This Use-Case describes how Connecting Party can issue invoices for Swift or similar wire bank transfer systems in Payment Gateway and display these invoices to Payers. Incoming bank transfer statuses might be updated automatically or manually.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Bank Wire Transfer Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Purchase payment request ==
  Merchant -> g: api/v2/auth-cash
  activate g
  g --> Merchant: orderId
  g --> g: Generating payment invoice
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage, receipt-id=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
  deactivate g
  == Get invoice in XML, PDF or both ==
  group XML
  g <-- Merchant: view-invoice-xml/ENDPOINTID/receipt-id
  activate g
  g --> Merchant: XML
  deactivate g
  end
  group PDF
  g <-- Merchant: view-invoice/ENDPOINTID/receipt-id
  activate g
  g --> Merchant: PDF
  deactivate g
  end
  Merchant -> Customer: Show result
  deactivate Merchant
```

(2) To implement bank transfer request see [/api/v2/auth-cash/](https://doc.payneteasy.com/integration/API_commands/api_v2_auth-cash.html.md).
 
(5,6) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response. receipt-id will be received in status response.
 
(7) To implement callback with final status handling see [Connecting Party](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(9) To implement view-invoice-xml request see [/view-invoice-xml/](https://doc.payneteasy.com/integration/API_commands/view-invoice-xml.html.md). receipt-id will be used to get invoice in XML format.
 
(11) To implement view-invoice request see [/view-invoice/](https://doc.payneteasy.com/integration/API_commands/view-invoice.html.md). receipt-id will be used to get invoice in PDF format.
 

#### Simple Bank Transfer Flow Statuses

| Stage name | Description |
|-------------------|---------------------------------------------------------------------------------------------------------------------------|
| AUTH_APPROVED | Invoice was issued for the Payer. |
| CANCEL_APPROVED | Payer didn’t complete the transfer. This stage is optional and may be used for better transaction control in back-office. |
| CAPTURE_APPROVED | Funds were transferred to the Connecting Party account (settled). |
| VOID_APPROVED | Funds were returned by the Payer (recalled). |
| REVERSAL_APPROVED | Funds were returned to the Payer by Connecting Party. |

#### Extended Bank Transfer Flow Statuses

| Stage name | Description |
|---------------------|---------------------------------------------------------------------------------------------------------------------------|
| AUTH_STARTING | Transaction was initiated. |
| AUTH_INVOICED | Invoice was issued for the Payer. It may be downloaded in back-office, sent to Payer by e-mail or requested via API. |
| AUTH_SENT | Payer informed the Connecting Party that invoice have been paid. This stage may be skipped. |
| CANCEL_APPROVED | Payer didn’t complete the transfer. This stage is optional and may be used for better transaction control in back-office. |
| AUTH_APPROVED | Transfer was received by the bank. |
| CAPTURE_APPROVED | Funds were transferred to the Connecting Party account (settled). |
| VOID_APPROVED | Funds were returned by the Payer (recalled). |
| REVERSAL_APPROVED | Funds were returned to the Payer by Connecting Party. |
| CHARGEBACK_APPROVED | Funds were charged back by the Payer. |

### Bitrix24

The Bitrix24 (1C-Bitrix) plugin is a payment module that adds Payneteasy as a payment system handler inside a Bitrix online store. It is distributed as a PHP module folder that is uploaded to the site via FTP and then activated through the Bitrix Marketplace, after which it can be selected as a payment handler for a store’s payment systems.

Documentation for this plugin is intentionally brief, since it mostly points to the plugin’s source repository and the (Russian- and English-language) installation notes published alongside it.

#### Source code

The plugin source is published on Git Hub: [php-plugin-bitrix](https://github.com/payneteasy/php-plugin-bitrix). The repository contains the plugin module itself, in a folder named `payneteasypayments.ecom`, together with a plain-text installation guide.

An accompanying documentation repository is also available: [bitrix-doc](https://github.com/annihilatoratm/bitrix-doc), which links to an [English-language installation guide](https://github.com/annihilatoratm/bitrix-doc/blob/main/documentation/doc-eng.md).

### Buy Now Button

#### Introduction

Buy Now Button integration is relevant for Connecting Party who has limited portfolio of products to sell. It is the easiest way to integrate with Payneteasy. This way of integration doesn’t require much technical effort. Buy Now Button integration also allows Connecting Party to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted customer details form and payment form in PCI DSS certified environment.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
1. Payer clicks on Buy Now Button, gets redirected to customer details form provided by Payment Gateway and submits customer data;

`Buy Now Button Form`
1. Payers then gets redirected to payment form and submits payment (cardholder) data.

1. Contextual data is gathered by Payneteasy to process the transaction, Payer stays on wait form until transaction is finished;

1. Payer’s browser gets redirected to the Connecting Party website to the resultant page.

#### Required Parameters for Buy Now Button Integration

Connecting Party provides to Payment Gateway support the following information for each product (item): Amount, Description, Final Redirect URL, Destination (purpose of payment) and Payment tool (payment method).
 
Payment Gateway provides to Connecting Party the Buy Now Button URLs for each product (item). URLs have the following format:
 

| Integration | Production |
|-------------------------------------------------------------------|----------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/v2/pay/ENDPOINTID/ITEMID | https://gate.payneteasy.eu/paynet/api/v2/pay/ENDPOINTID/ITEMID |

#### Buy Now Button Form Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Customer
  activate Merchant
  Customer <-- Merchant: Display Buy Now Button
  deactivate Merchant
  Customer -> g: Redirect to Buy Now Button form
  activate g
  g --> Customer: Return customer details form
  deactivate g
  g <- Customer: Submit customer details form
  activate g
  g --> Customer: Return payment form
  deactivate g
  Customer -> g: Submit payment form
  deactivate Customer
  activate g
  g --> g: Process payment
  == Final redirect of customer ==
  g -> Customer: Connecting Party website redirect_url
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  activate Merchant
  group Get Final Status
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant -> Customer: Show result
  deactivate Merchant
```

(2) Place the Buy Now Button HTML element on checkout page available for the Payer.
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11,12) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Connecting Party may request order status after receiving transaction ID in either Connecting Party callback or final redirect.
 
(13) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).

### Common Utilities

### Country and State Codes

#### Country Codes

* Alpha-2 country codes are used in country field.
* Alpha-3 codes are returned in status response and callback in card-country-alpha-three-code and destination-card-country-alpha-three-code parameters.
* ISO Codes are used in Payment Gateway configurations.

| Country | Alpha-2 Code | Alpha-3 Code | ISO Code |
|----------------------------------------------|----------------|----------------|------------|
| Åland Islands | AX | ALA | 248 |
| Afghanistan | AF | AFG | 004 |
| Albania | AL | ALB | 008 |
| Algeria | DZ | DZA | 012 |
| American Samoa | AS | ASM | 016 |
| Andorra | AD | AND | 020 |
| Angola | AO | AGO | 024 |
| Anguilla | AI | AIA | 660 |
| Antarctica | AQ | ATA | 010 |
| Antigua and Barbuda | AG | ATG | 028 |
| Argentina | AR | ARG | 032 |
| Armenia | AM | ARM | 051 |
| Aruba | AW | ABW | 533 |
| Australia | AU | AUS | 036 |
| Austria | AT | AUT | 040 |
| Azerbaijan | AZ | AZE | 031 |
| Bahamas | BS | BHS | 044 |
| Bahrain | BH | BHR | 048 |
| Bangladesh | BD | BGD | 050 |
| Barbados | BB | BRB | 052 |
| Belarus | BY | BLR | 112 |
| Belgium | BE | BEL | 056 |
| Belize | BZ | BLZ | 084 |
| Benin | BJ | BEN | 204 |
| Bermuda | BM | BMU | 060 |
| Bhutan | BT | BTN | 064 |
| Bolivia, Plurinational State of | BO | BOL | 068 |
| Bosnia and Herzegovina | BA | BIH | 070 |
| Botswana | BW | BWA | 072 |
| Bouvet Island | BV | BVT | 074 |
| Brazil | BR | BRA | 076 |
| British Indian Ocean Territory | IO | IOT | 086 |
| Brunei Darussalam | BN | BRN | 096 |
| Bulgaria | BG | BGR | 100 |
| Burkina Faso | BF | BFA | 854 |
| Burundi | BI | BDI | 108 |
| Cambodia | KH | KHM | 116 |
| Cameroon | CM | CMR | 120 |
| Canada | CA | CAN | 124 |
| Cabo Verde | CV | CPV | 132 |
| Cayman Islands | KY | CYM | 136 |
| Central African Republic | CF | CAF | 140 |
| Chad | TD | TCD | 148 |
| Chile | CL | CHL | 152 |
| China | CN | CHN | 156 |
| Christmas Island | CX | CXR | 162 |
| Cocos (Keeling) Islands | CC | CCK | 166 |
| Colombia | CO | COL | 170 |
| Comoros | KM | COM | 174 |
| Congo | CG | COG | 178 |
| Congo, the Democratic Republic of the | CD | COD | 180 |
| Cook Islands | CK | COK | 184 |
| Costa Rica | CR | CRI | 188 |
| Cote d’Ivoire | CI | CIV | 384 |
| Croatia | HR | HRV | 191 |
| Cuba | CU | CUB | 192 |
| Cyprus | CY | CYP | 196 |
| Czechia | CZ | CZE | 203 |
| Denmark | DK | DNK | 208 |
| Djibouti | DJ | DJI | 262 |
| Dominica | DM | DMA | 212 |
| Dominican Republic | DO | DOM | 214 |
| Ecuador | EC | ECU | 218 |
| Egypt | EG | EGY | 818 |
| El Salvador | SV | SLV | 222 |
| Equatorial Guinea | GQ | GNQ | 226 |
| Eritrea | ER | ERI | 232 |
| Estonia | EE | EST | 233 |
| Ethiopia | ET | ETH | 231 |
| Falkland Islands (Malvinas) | FK | FLK | 238 |
| Faroe Islands | FO | FRO | 234 |
| Fiji | FJ | FJI | 242 |
| Finland | FI | FIN | 246 |
| France | FR | FRA | 250 |
| French Guiana | GF | GUF | 254 |
| French Polynesia | PF | PYF | 258 |
| French Southern Territories | TF | ATF | 260 |
| Gabon | GA | GAB | 266 |
| Gambia | GM | GMB | 270 |
| Georgia | GE | GEO | 268 |
| Germany | DE | DEU | 276 |
| Ghana | GH | GHA | 288 |
| Gibraltar | GI | GIB | 292 |
| Greece | GR | GRC | 300 |
| Greenland | GL | GRL | 304 |
| Grenada | GD | GRD | 308 |
| Guadeloupe | GP | GLP | 312 |
| Guam | GU | GUM | 316 |
| Guatemala | GT | GTM | 320 |
| Guernsey | GG | GGY | 831 |
| Guinea | GN | GIN | 324 |
| Guinea-Bissau | GW | GNB | 624 |
| Guyana | GY | GUY | 328 |
| Haiti | HT | HTI | 332 |
| Heard Island and Mc Donald Islands | HM | HMD | 334 |
| Holy See (Vatican City State) | VA | VAT | 336 |
| Honduras | HN | HND | 340 |
| Hong Kong | HK | HKG | 344 |
| Hungary | HU | HUN | 348 |
| Iceland | IS | ISL | 352 |
| India | IN | IND | 356 |
| Indonesia | ID | IDN | 360 |
| Iran, Islamic Republic of | IR | IRN | 364 |
| Iraq | IQ | IRQ | 368 |
| Ireland | IE | IRL | 372 |
| Isle of Man | IM | IMN | 833 |
| Israel | IL | ISR | 376 |
| Italy | IT | ITA | 380 |
| Jamaica | JM | JAM | 388 |
| Japan | JP | JPN | 392 |
| Jersey | JE | JEY | 832 |
| Jordan | JO | JOR | 400 |
| Kazakhstan | KZ | KAZ | 398 |
| Kenya | KE | KEN | 404 |
| Kosovo | XK | XKX | 983 |
| Kiribati | KI | KIR | 296 |
| Korea, Democratic People’s Republic of | KP | PRK | 408 |
| Korea, Republic of | KR | KOR | 410 |
| Kuwait | KW | KWT | 414 |
| Kyrgyzstan | KG | KGZ | 417 |
| Lao People’s Democratic Republic | LA | LAO | 418 |
| Latvia | LV | LVA | 428 |
| Lebanon | LB | LBN | 422 |
| Lesotho | LS | LSO | 426 |
| Liberia | LR | LBR | 430 |
| Libya | LY | LBY | 434 |
| Liechtenstein | LI | LIE | 438 |
| Lithuania | LT | LTU | 440 |
| Luxembourg | LU | LUX | 442 |
| Macao | MO | MAC | 446 |
| North Macedonia | MK | MKD | 807 |
| Madagascar | MG | MDG | 450 |
| Malawi | MW | MWI | 454 |
| Malaysia | MY | MYS | 458 |
| Maldives | MV | MDV | 462 |
| Mali | ML | MLI | 466 |
| Malta | MT | MLT | 470 |
| Marshall Islands | MH | MHL | 584 |
| Martinique | MQ | MTQ | 474 |
| Mauritania | MR | MRT | 478 |
| Mauritius | MU | MUS | 480 |
| Mayotte | YT | MYT | 175 |
| Mexico | MX | MEX | 484 |
| Micronesia, Federated States of | FM | FSM | 583 |
| Moldova, Republic of | MD | MDA | 498 |
| Monaco | MC | MCO | 492 |
| Mongolia | MN | MNG | 496 |
| Montenegro | ME | MNE | 499 |
| Montserrat | MS | MSR | 500 |
| Morocco | MA | MAR | 504 |
| Mozambique | MZ | MOZ | 508 |
| Myanmar | MM | MMR | 104 |
| Namibia | NA | NAM | 516 |
| Nauru | NR | NRU | 520 |
| Nepal | NP | NPL | 524 |
| Netherlands | NL | NLD | 528 |
| New Caledonia | NC | NCL | 540 |
| New Zealand | NZ | NZL | 554 |
| Nicaragua | NI | NIC | 558 |
| Niger | NE | NER | 562 |
| Nigeria | NG | NGA | 566 |
| Niue | NU | NIU | 570 |
| Norfolk Island | NF | NFK | 574 |
| Northern Mariana Islands | MP | MNP | 580 |
| Norway | NO | NOR | 578 |
| Oman | OM | OMN | 512 |
| Pakistan | PK | PAK | 586 |
| Palau | PW | PLW | 585 |
| Palestine, State of | PS | PSE | 275 |
| Panama | PA | PAN | 591 |
| Papua New Guinea | PG | PNG | 598 |
| Paraguay | PY | PRY | 600 |
| Peru | PE | PER | 604 |
| Philippines | PH | PHL | 608 |
| Pitcairn | PN | PCN | 612 |
| Poland | PL | POL | 616 |
| Portugal | PT | PRT | 620 |
| Puerto Rico | PR | PRI | 630 |
| Qatar | QA | QAT | 634 |
| Reunion | RE | REU | 638 |
| Romania | RO | ROU | 642 |
| Russian Federation | RU | RUS | 643 |
| Rwanda | RW | RWA | 646 |
| Saint Barthelemy | BL | BLM | 652 |
| Saint Helena, Ascension and Tristan da Cunha | SH | SHN | 654 |
| Saint Kitts and Nevis | KN | KNA | 659 |
| Saint Lucia | LC | LCA | 662 |
| Saint Martin (French part) | MF | MAF | 663 |
| Saint Pierre and Miquelon | PM | SPM | 666 |
| Saint Vincent and the Grenadines | VC | VCT | 670 |
| Samoa | WS | WSM | 882 |
| San Marino | SM | SMR | 674 |
| Sao Tome and Principe | ST | STP | 678 |
| Saudi Arabia | SA | SAU | 682 |
| Senegal | SN | SEN | 686 |
| Serbia | RS | SRB | 688 |
| Seychelles | SC | SYC | 690 |
| Sierra Leone | SL | SLE | 694 |
| Singapore | SG | SGP | 702 |
| Slovakia | SK | SVK | 703 |
| Slovenia | SI | SVN | 705 |
| Solomon Islands | SB | SLB | 090 |
| Somalia | SO | SOM | 706 |
| South Africa | ZA | ZAF | 710 |
| South Georgia and the South Sandwich Islands | GS | SGS | 239 |
| Spain | ES | ESP | 724 |
| Sri Lanka | LK | LKA | 144 |
| Sudan | SD | SDN | 729 |
| Suriname | SR | SUR | 740 |
| Svalbard and Jan Mayen | SJ | SJM | 744 |
| Eswatini | SZ | SWZ | 748 |
| Sweden | SE | SWE | 752 |
| Switzerland | CH | CHE | 756 |
| Syrian Arab Republic | SY | SYR | 760 |
| Taiwan, Province of China | TW | TWN | 158 |
| Tajikistan | TJ | TJK | 762 |
| Tanzania, United Republic of | TZ | TZA | 834 |
| Thailand | TH | THA | 764 |
| Timor-Leste | TL | TLS | 626 |
| Togo | TG | TGO | 768 |
| Tokelau | TK | TKL | 772 |
| Tonga | TO | TON | 776 |
| Trinidad and Tobago | TT | TTO | 780 |
| Tunisia | TN | TUN | 788 |
| Türkiye | TR | TUR | 792 |
| Turkmenistan | TM | TKM | 795 |
| Turks and Caicos Islands | TC | TCA | 796 |
| Tuvalu | TV | TUV | 798 |
| Uganda | UG | UGA | 800 |
| Ukraine | UA | UKR | 804 |
| United Arab Emirates | AE | ARE | 784 |
| United Kingdom | GB | GBR | 826 |
| United States | US | USA | 840 |
| United States Minor Outlying Islands | UM | UMI | 581 |
| Uruguay | UY | URY | 858 |
| Uzbekistan | UZ | UZB | 860 |
| Vanuatu | VU | VUT | 548 |
| Venezuela, Bolivarian Republic of | VE | VEN | 862 |
| Viet Nam | VN | VNM | 704 |
| Virgin Islands, British | VG | VGB | 092 |
| Virgin Islands, U.S. | VI | VIR | 850 |
| Wallis and Futuna | WF | WLF | 876 |
| Western Sahara | EH | ESH | 732 |
| Yemen | YE | YEM | 887 |
| Zambia | ZM | ZMB | 894 |
| Zimbabwe | ZW | ZWE | 716 |
| Sint Maarten (Dutch part) | SX | SXM | 534 |
| Curaçao | CW | CUW | 531 |
| Bonaire, Sint Eustatius and Saba | BQ | BES | 535 |
| South Sudan | SS | SSD | 728 |

#### Mandatory State Codes

Mandatory state codes used in state field for USA, Canada and Australia.

| Country | State Code | State Name |
|-----------|--------------|------------------------------|
| AU | ACT | Australian Capital Territory |
| AU | NSW | New South Wales |
| AU | NT | Northern Territory |
| AU | QLD | Queensland |
| AU | SA | South Australia |
| AU | TAS | Tasmania |
| AU | VIC | Victoria |
| AU | WA | Western Australia |
| CA | AB | Alberta |
| CA | BC | British Columbia |
| CA | MB | Manitoba |
| CA | NB | New Brunswick |
| CA | NL | Newfoundland and Labrador |
| CA | NT | Northwest Territories |
| CA | NS | Nova Scotia |
| CA | NU | Nunavut |
| CA | ON | Ontario |
| CA | PE | Prince Edward Island |
| CA | QC | Quebec |
| CA | SK | Saskatchewan |
| CA | YT | Yukon |
| US | AL | Alabama |
| US | AK | Alaska |
| US | AS | American Samoa |
| US | AZ | Arizona |
| US | AR | Arkansas |
| US | CA | California |
| US | CO | Colorado |
| US | CT | Connecticut |
| US | DE | Delaware |
| US | DC | District of Columbia |
| US | FL | Florida |
| US | GA | Georgia |
| US | GU | Guam |
| US | HI | Hawaii |
| US | ID | Idaho |
| US | IL | Illinois |
| US | IN | Indiana |
| US | IA | Iowa |
| US | KS | Kansas |
| US | KY | Kentucky |
| US | LA | Louisiana |
| US | ME | Maine |
| US | MD | Maryland |
| US | MA | Massachusetts |
| US | MI | Michigan |
| US | MN | Minnesota |
| US | MS | Mississippi |
| US | MO | Missouri |
| US | MT | Montana |
| US | NE | Nebraska |
| US | NV | Nevada |
| US | NH | New Hampshire |
| US | NJ | New Jersey |
| US | NM | New Mexico |
| US | NY | New York |
| US | NC | North Carolina |
| US | ND | North Dakota |
| US | OH | Ohio |
| US | OK | Oklahoma |
| US | OR | Oregon |
| US | PA | Pennsylvania |
| US | PR | Puerto Rico |
| US | RI | Rhode Island |
| US | SC | South Carolina |
| US | SD | South Dakota |
| US | TN | Tennessee |
| US | TX | Texas |
| US | UT | Utah |
| US | VT | Vermont |
| US | VI | Virgin Islands |
| US | VA | Virginia |
| US | WA | Washington |
| US | WV | West Virginia |
| US | WI | Wisconsin |
| US | WY | Wyoming |

#### Other State Codes

Optional state codes used in state field. Depending on the processing channel these codes can also be mandatory.

| Country | ISO 3166-2 Сode | State Name |
|-----------|-------------------|-----------------------------------------------------------------------------|
| AF | BDS | Badakhshan |
| AF | BDG | Badghis |
| AF | BGL | Baghlan |
| AF | BAL | Balkh |
| AF | BAM | Bamian |
| AF | FRA | Farah |
| AF | FYB | Faryab |
| AF | GHA | Ghazni |
| AF | GHO | Ghowr |
| AF | HEL | Helmand |
| AF | HER | Herat |
| AF | JOW | Jowzjan |
| AF | KAB | Kabul |
| AF | KAN | Kandahar |
| AF | KAP | Kapisa |
| AF | KHO | Khost |
| AF | KNR | Konar |
| AF | KDZ | Kondoz |
| AF | LAG | Laghman |
| AF | NAN | Nangrahar |
| AF | NIM | Nimruz |
| AF | NUR | Nurestan |
| AF | PIA | Paktia |
| AF | PKA | Paktika |
| AF | PAR | Parwan |
| AF | SAM | Samangan |
| AF | SAR | Sar-e Pol |
| AF | TAK | Takhar |
| AF | WAR | Wardak |
| AF | DAY | Dāykundī |
| AF | LOG | Lōgar |
| AF | PAN | Panjshayr |
| AF | URU | Uruzgān |
| AF | ZAB | Zābul |
| AL | 01 | Berat |
| AL | 09 | Diber |
| AL | 02 | Durres |
| AL | 03 | Elbasan |
| AL | 04 | Fier |
| AL | 05 | Gjirokaster |
| AL | 06 | Korce |
| AL | 07 | Kukes |
| AL | 08 | Lezhe |
| AL | 10 | Shkoder |
| AL | 11 | Tirane |
| AL | 12 | Vlore |
| DZ | 01 | Adrar |
| DZ | 44 | Ain Defla |
| DZ | 46 | Ain Temouchent |
| DZ | 16 | Alger |
| DZ | 23 | Annaba |
| DZ | 05 | Batna |
| DZ | 08 | Bechar |
| DZ | 06 | Bejaia |
| DZ | 07 | Biskra |
| DZ | 09 | Blida |
| DZ | 34 | Bordj Bou Arreridj |
| DZ | 10 | Bouira |
| DZ | 35 | Boumerdes |
| DZ | 02 | Chlef |
| DZ | 25 | Constantine |
| DZ | 17 | Djelfa |
| DZ | 32 | El Bayadh |
| DZ | 39 | El Oued |
| DZ | 36 | El Tarf |
| DZ | 47 | Ghardaia |
| DZ | 24 | Guelma |
| DZ | 33 | Illizi |
| DZ | 18 | Jijel |
| DZ | 40 | Khenchela |
| DZ | 03 | Laghouat |
| DZ | 28 | M’Sila |
| DZ | 26 | Medea |
| DZ | 43 | Mila |
| DZ | 27 | Mostaganem |
| DZ | 45 | Naama |
| DZ | 31 | Oran |
| DZ | 30 | Ouargla |
| DZ | 48 | Relizane |
| DZ | 20 | Saida |
| DZ | 19 | Setif |
| DZ | 22 | Sidi Bel Abbes |
| DZ | 21 | Skikda |
| DZ | 41 | Souk Ahras |
| DZ | 12 | Tebessa |
| DZ | 14 | Tiaret |
| DZ | 37 | Tindouf |
| DZ | 42 | Tipaza |
| DZ | 38 | Tissemsilt |
| DZ | 15 | Tizi Ouzou |
| DZ | 13 | Tlemcen |
| DZ | 04 | Oum el Bouaghi |
| DZ | 11 | Tamanrasset |
| DZ | 29 | Mascara |
| AD | 07 | Andorra la Vella |
| AD | 02 | Canillo |
| AD | 03 | Encamp |
| AD | 08 | Escaldes-Engordany |
| AD | 04 | La Massana |
| AD | 05 | Ordino |
| AD | 06 | Sant Julia de Loria |
| AO | BGO | Bengo |
| AO | BGU | Benguela |
| AO | BIE | Bie |
| AO | CAB | Cabinda |
| AO | CCU | Cuando-Cubango |
| AO | CNO | Cuanza Norte |
| AO | CUS | Cuanza Sul |
| AO | CNN | Cunene |
| AO | HUA | Huambo |
| AO | HUI | Huila |
| AO | LUA | Luanda |
| AO | LNO | Lunda Norte |
| AO | LSU | Lunda Sul |
| AO | MAL | Malange |
| AO | MOX | Moxico |
| AO | NAM | Namibe |
| AO | UIG | Uige |
| AO | ZAI | Zaire |
| AG | 10 | Barbuda |
| AG | 11 | Redonda |
| AG | 03 | Saint George |
| AG | 04 | Saint John |
| AG | 05 | Saint Mary |
| AG | 06 | Saint Paul |
| AG | 07 | Saint Peter |
| AG | 08 | Saint Philip |
| AR | B | Buenos Aires |
| AR | K | Catamarca |
| AR | H | Chaco |
| AR | U | Chubut |
| AR | X | Cordoba |
| AR | W | Corrientes |
| AR | E | Entre Rios |
| AR | P | Formosa |
| AR | Y | Jujuy |
| AR | L | La Pampa |
| AR | F | La Rioja |
| AR | M | Mendoza |
| AR | N | Misiones |
| AR | Q | Neuquen |
| AR | R | Rio Negro |
| AR | A | Salta |
| AR | J | San Juan |
| AR | D | San Luis |
| AR | Z | Santa Cruz |
| AR | S | Santa Fe |
| AR | G | Santiago del Estero |
| AR | V | Tierra del Fuego |
| AR | T | Tucuman |
| AR | C | Ciudad Autónoma de Buenos Aires |
| AM | AR | Ararat |
| AM | AV | Armavir |
| AM | KT | Kotayk’ |
| AM | SU | Syunik’ |
| AM | AG | Aragac̣otn |
| AM | ER | Erevan |
| AM | GR | Geġark’unik’ |
| AM | LO | Loṙi |
| AM | SH | Širak |
| AM | TV | Tavuš |
| AM | VD | Vayoć Jor |
| AT | 1 | Burgenland |
| AT | 3 | Niederösterreich |
| AT | 5 | Salzburg |
| AT | 6 | Steiermark |
| AT | 7 | Tirol |
| AT | 8 | Vorarlberg |
| AT | 9 | Wien |
| AT | 2 | Kärnten |
| AT | 4 | Oberösterreich |
| AZ | ABS | Abseron |
| AZ | AGC | Agcab Adi |
| AZ | AGM | Agdam |
| AZ | AGS | Agdas |
| AZ | AGA | Agstafa |
| AZ | AGU | Agsu |
| AZ | AST | Astara |
| AZ | BAR | BArdA |
| AZ | BAB | Bab Ak |
| AZ | BA | Baki |
| AZ | BAL | Balak An |
| AZ | BEY | Beylaqan |
| AZ | BIL | Bilasuvar |
| AZ | CAB | Cabrayil |
| AZ | CAL | Calilabab |
| AZ | CUL | Culfa |
| AZ | DAS | Daskasan |
| AZ | FUZ | Fuzuli |
| AZ | GAD | Gadabay |
| AZ | GA | Ganca |
| AZ | GOR | Goranboy |
| AZ | GOY | Goycay |
| AZ | HAC | Haciqabul |
| AZ | IMI | Imisli |
| AZ | ISM | Ismayilli |
| AZ | KAL | Kalbacar |
| AZ | KUR | Kurdamir |
| AZ | LAC | Lacin |
| AZ | LA | Lankaran |
| AZ | LER | Lerik |
| AZ | MAS | Masalli |
| AZ | MI | Mingacevir |
| AZ | NA | Naftalan |
| AZ | NX | Naxcivan |
| AZ | NEF | Neftcala |
| AZ | OGU | Oguz |
| AZ | ORD | Ordubad |
| AZ | QAB | Qabala |
| AZ | QAX | Qax |
| AZ | QAZ | Qazax |
| AZ | QOB | Qobustan |
| AZ | QBA | Quba |
| AZ | QBI | Qubadli |
| AZ | QUS | Qusar |
| AZ | SAT | Saatli |
| AZ | SAB | Sabirabad |
| AZ | SAD | Sadarak |
| AZ | SAH | Sahbuz |
| AZ | SA | Saki |
| AZ | SAL | Salyan |
| AZ | SMI | Samaxi |
| AZ | SKR | Samkir |
| AZ | SMX | Samux |
| AZ | SAR | Sarur |
| AZ | SIY | Siyazan |
| AZ | SM | Sumqayit |
| AZ | SUS | Susa |
| AZ | TAR | Tartar |
| AZ | TOV | Tovuz |
| AZ | UCA | Ucar |
| AZ | XAC | Xacmaz |
| AZ | XA | Xankandi |
| AZ | XIZ | Xizi |
| AZ | XCI | Xocali |
| AZ | XVD | Xocavand |
| AZ | YAR | Yardimli |
| AZ | YE | Yevlax |
| AZ | ZAN | Zangilan |
| AZ | ZAQ | Zaqatala |
| AZ | ZAR | Zardab |
| AZ | GYG | Göygöl |
| AZ | KAN | Kǝngǝrli |
| AZ | SBN | Şabran |
| AZ | SR | Şirvan |
| BS | AK | Acklins |
| BS | BY | Berry Islands |
| BS | BI | Bimini |
| BS | BP | Black Point |
| BS | CI | Cat Island |
| BS | CO | Central Abaco |
| BS | CS | Central Andros |
| BS | CE | Central Eleuthera |
| BS | FP | City of Freeport |
| BS | EG | East Grand Bahama |
| BS | EX | Exuma |
| BS | GC | Grand Cay |
| BS | HI | Harbour Island |
| BS | HT | Hope Town |
| BS | IN | Inagua |
| BS | LI | Long Island |
| BS | MC | Mangrove Cay |
| BS | MG | Mayaguana |
| BS | MI | Moore’s Island |
| BS | NO | North Abaco |
| BS | NS | North Andros |
| BS | NE | North Eleuthera |
| BS | RI | Ragged Island |
| BS | RC | Rum Cay |
| BS | SS | San Salvador |
| BS | SO | South Abaco |
| BS | SA | South Andros |
| BS | SE | South Eleuthera |
| BS | SW | Spanish Wells |
| BS | WG | West Grand Bahama |
| BS | CK | Crooked Island and Long Cay |
| BS | NP | New Providence |
| BH | 13 | Al ‘Āşimah |
| BH | 14 | Al Janūbīyah |
| BH | 15 | Al Muḩarraq |
| BH | 17 | Ash Shamālīyah |
| BD | C | Dhaka |
| BD | D | Khulna |
| BD | E | Rajshahi |
| BD | G | Sylhet |
| BD | 01 | Bandarban |
| BD | 02 | Barguna |
| BD | 03 | Bogura |
| BD | 04 | Brahmanbaria |
| BD | 05 | Bagerhat |
| BD | 06 | Barishal |
| BD | 07 | Bhola |
| BD | 08 | Cumilla |
| BD | 09 | Chandpur |
| BD | 10 | Chattogram |
| BD | 11 | Cox’s Bazar |
| BD | 12 | Chuadanga |
| BD | 14 | Dinajpur |
| BD | 15 | Faridpur |
| BD | 16 | Feni |
| BD | 17 | Gopalganj |
| BD | 18 | Gazipur |
| BD | 19 | Gaibandha |
| BD | 20 | Habiganj |
| BD | 21 | Jamalpur |
| BD | 22 | Jashore |
| BD | 23 | Jhenaidah |
| BD | 24 | Joypurhat |
| BD | 25 | Jhalakathi |
| BD | 26 | Kishoreganj |
| BD | 28 | Kurigram |
| BD | 29 | Khagrachhari |
| BD | 30 | Kushtia |
| BD | 31 | Lakshmipur |
| BD | 32 | Lalmonirhat |
| BD | 33 | Manikganj |
| BD | 34 | Mymensingh |
| BD | 35 | Munshiganj |
| BD | 36 | Madaripur |
| BD | 37 | Magura |
| BD | 38 | Moulvibazar |
| BD | 39 | Meherpur |
| BD | 40 | Narayanganj |
| BD | 41 | Netrakona |
| BD | 42 | Narsingdi |
| BD | 43 | Narail |
| BD | 44 | Natore |
| BD | 45 | Chapai Nawabganj |
| BD | 46 | Nilphamari |
| BD | 47 | Noakhali |
| BD | 48 | Naogaon |
| BD | 49 | Pabna |
| BD | 50 | Pirojpur |
| BD | 51 | Patuakhali |
| BD | 52 | Panchagarh |
| BD | 53 | Rajbari |
| BD | 55 | Rangpur |
| BD | 56 | Rangamati |
| BD | 57 | Sherpur |
| BD | 58 | Satkhira |
| BD | 59 | Sirajganj |
| BD | 61 | Sunamganj |
| BD | 62 | Shariatpur |
| BD | 63 | Tangail |
| BD | 64 | Thakurgaon |
| BD | A | Barishal |
| BD | B | Chattogram |
| BD | F | Rangpur |
| BD | H | Mymensingh |
| BB | 01 | Christ Church |
| BB | 02 | Saint Andrew |
| BB | 03 | Saint George |
| BB | 04 | Saint James |
| BB | 05 | Saint John |
| BB | 06 | Saint Joseph |
| BB | 07 | Saint Lucy |
| BB | 08 | Saint Michael |
| BB | 09 | Saint Peter |
| BB | 10 | Saint Philip |
| BB | 11 | Saint Thomas |
| BY | BR | Brestskaya (Brest) |
| BY | HO | Homyel’skaya (Homyel’) |
| BY | HM | Horad Minsk |
| BY | HR | Hrodzyenskaya (Hrodna) |
| BY | MA | Mahilyowskaya (Mahilyow) |
| BY | MI | Minskaya |
| BY | VI | Vitsyebskaya (Vitsyebsk) |
| BE | VAN | Antwerpen |
| BE | WBR | Brabant Wallon |
| BE | WHT | Hainaut |
| BE | WLG | Liege |
| BE | VLI | Limburg |
| BE | WLX | Luxembourg |
| BE | WNA | Namur |
| BE | VOV | Oost-Vlaanderen |
| BE | VBR | Vlaams Brabant |
| BE | VWV | West-Vlaanderen |
| BE | BRU | “Bruxelles-Capitale, Région de” |
| BE | VLG | Vlaams Gewest |
| BE | WAL | “wallonne, Région” |
| BZ | BZ | Belize |
| BZ | CY | Cayo |
| BZ | CZL | Corozal |
| BZ | OW | Orange Walk |
| BZ | SC | Stann Creek |
| BZ | TOL | Toledo |
| BJ | AL | Alibori |
| BJ | AK | Atakora |
| BJ | AQ | Atlantique |
| BJ | BO | Borgou |
| BJ | CO | Collines |
| BJ | DO | Donga |
| BJ | KO | Kouffo |
| BJ | LI | Littoral |
| BJ | MO | Mono |
| BJ | OU | Oueme |
| BJ | PL | Plateau |
| BJ | ZO | Zou |
| BT | 33 | Bumthang |
| BT | 22 | Dagana |
| BT | GA | Gasa |
| BT | 13 | Haa |
| BT | 11 | Paro |
| BT | 23 | Punakha |
| BT | 45 | Samdrup Jongkhar |
| BT | 14 | Samtse |
| BT | 31 | Sarpang |
| BT | 15 | Thimphu |
| BT | 41 | Trashigang |
| BT | 32 | Trongsa |
| BT | 21 | Tsirang |
| BT | 24 | Wangdue Phodrang |
| BT | 34 | Zhemgang |
| BT | 12 | Chhukha |
| BT | 42 | Monggar |
| BT | 43 | Pema Gatshel |
| BT | 44 | Lhuentse |
| BT | TY | Trashi Yangtse |
| BO | H | Chuquisaca |
| BO | C | Cochabamba |
| BO | L | La Paz |
| BO | O | Oruro |
| BO | N | Pando |
| BO | P | Potosi |
| BO | S | Santa Cruz |
| BO | T | Tarija |
| BO | B | El Beni |
| BA | BIH | Federacija Bosne i Hercegovine |
| BA | BRC | Brčko distrikt |
| BA | SRP | Republika Srpska |
| BW | CE | Central |
| BW | GH | Ghanzi |
| BW | KG | Kgalagadi |
| BW | KL | Kgatleng |
| BW | KW | Kweneng |
| BW | NE | North East |
| BW | NW | North West |
| BW | SE | South East |
| BW | SO | Southern |
| BW | CH | Chobe |
| BW | FR | Francistown |
| BW | GA | Gaborone |
| BW | JW | Jwaneng |
| BW | LO | Lobatse |
| BW | SP | Selibe Phikwe |
| BW | ST | Sowa Town |
| BR | AC | Acre |
| BR | AL | Alagoas |
| BR | AP | Amapa |
| BR | AM | Amazonas |
| BR | BA | Bahia |
| BR | CE | Ceara |
| BR | DF | Distrito Federal |
| BR | ES | Espirito Santo |
| BR | GO | Goias |
| BR | MA | Maranhao |
| BR | MT | Mato Grosso |
| BR | MS | Mato Grosso do Sul |
| BR | MG | Minas Gerais |
| BR | PA | Para |
| BR | PB | Paraiba |
| BR | PR | Parana |
| BR | PE | Pernambuco |
| BR | PI | Piaui |
| BR | RN | Rio Grande do Norte |
| BR | RS | Rio Grande do Sul |
| BR | RJ | Rio de Janeiro |
| BR | RO | Rondonia |
| BR | RR | Roraima |
| BR | SC | Santa Catarina |
| BR | SP | Sao Paulo |
| BR | SE | Sergipe |
| BR | TO | Tocantins |
| BN | BE | Belait |
| BN | TE | Temburong |
| BN | TU | Tutong |
| BN | BM | Brunei-Muara |
| BG | 01 | Blagoevgrad |
| BG | 02 | Burgas |
| BG | 08 | Dobrich |
| BG | 07 | Gabrovo |
| BG | 26 | Haskovo |
| BG | 09 | Kardjali |
| BG | 10 | Kyustendil |
| BG | 11 | Lovech |
| BG | 12 | Montana |
| BG | 13 | Pazardjik |
| BG | 14 | Pernik |
| BG | 15 | Pleven |
| BG | 16 | Plovdiv |
| BG | 17 | Razgrad |
| BG | 27 | Shumen |
| BG | 19 | Silistra |
| BG | 20 | Sliven |
| BG | 21 | Smolyan |
| BG | 23 | Sofia |
| BG | 22 | Sofia - town |
| BG | 24 | Stara Zagora |
| BG | 25 | Targovishte |
| BG | 03 | Varna |
| BG | 04 | Veliko Tarnovo |
| BG | 05 | Vidin |
| BG | 06 | Vratza |
| BG | 28 | Yambol |
| BG | 18 | Ruse |
| BF | BAL | Bale |
| BF | BAM | Bam |
| BF | BAN | Banwa |
| BF | BAZ | Bazega |
| BF | BGR | Bougouriba |
| BF | BLG | Boulgou |
| BF | BLK | Boulkiemde |
| BF | COM | Comoe |
| BF | GAN | Ganzourgou |
| BF | GNA | Gnagna |
| BF | GOU | Gourma |
| BF | HOU | Houet |
| BF | IOB | Ioba |
| BF | KAD | Kadiogo |
| BF | KEN | Kenedougou |
| BF | KMD | Komondjari |
| BF | KOP | Kompienga |
| BF | KOS | Kossi |
| BF | KOP | Koulpelogo |
| BF | KOT | Kouritenga |
| BF | KOW | Kourweogo |
| BF | LER | Leraba |
| BF | LOR | Loroum |
| BF | MOU | Mouhoun |
| BF | NAO | Nahouri |
| BF | NAM | Namentenga |
| BF | NAY | Nayala |
| BF | NOU | Noumbiel |
| BF | OUB | Oubritenga |
| BF | OUD | Oudalan |
| BF | PAS | Passore |
| BF | PON | Poni |
| BF | SNG | Sanguie |
| BF | SMT | Sanmatenga |
| BF | SEN | Seno |
| BF | SIS | Sissili |
| BF | SOM | Soum |
| BF | SOR | Sourou |
| BF | TAP | Tapoa |
| BF | TUI | Tuy |
| BF | YAG | Yagha |
| BF | YAT | Yatenga |
| BF | ZIR | Ziro |
| BF | ZON | Zondoma |
| BF | ZOU | Zoundweogo |
| BF | 01 | Boucle du Mouhoun |
| BF | 02 | Cascades |
| BF | 03 | Centre |
| BF | 04 | Centre-Est |
| BF | 05 | Centre-Nord |
| BF | 06 | Centre-Ouest |
| BF | 07 | Centre-Sud |
| BF | 08 | Est |
| BF | 09 | Hauts-Bassins |
| BF | 10 | Nord |
| BF | 11 | Plateau-Central |
| BF | 12 | Sahel |
| BF | 13 | Sud-Ouest |
| BI | BB | Bubanza |
| BI | BR | Bururi |
| BI | CA | Cankuzo |
| BI | CI | Cibitoke |
| BI | GI | Gitega |
| BI | KR | Karuzi |
| BI | KY | Kayanza |
| BI | KI | Kirundo |
| BI | MA | Makamba |
| BI | MU | Muramvya |
| BI | MY | Muyinga |
| BI | MW | Mwaro |
| BI | NG | Ngozi |
| BI | RT | Rutana |
| BI | RY | Ruyigi |
| BI | BL | Bujumbura Rural |
| BI | BM | Bujumbura Mairie |
| BI | RM | Rumonge |
| KH | 1 | Banteay Meanchey |
| KH | 3 | Kampong Cham |
| KH | 4 | Kampong Chhnang |
| KH | 7 | Kampot |
| KH | 8 | Kandal |
| KH | 9 | Kaoh Kong |
| KH | 23 | Keb |
| KH | 24 | Pailin |
| KH | 12 | Phnom Penh |
| KH | 13 | Preah Vihear |
| KH | 14 | Prey Veng |
| KH | 20 | Svay Rieng |
| KH | 10 | Krâchéh |
| KH | 11 | Môndól Kiri |
| KH | 15 | Poŭthĭsăt |
| KH | 16 | Rôtânôkiri |
| KH | 17 | Siĕmréab |
| KH | 18 | Preah Sihanouk |
| KH | 19 | Stueng Traeng |
| KH | 2 | Bătdâmbâng |
| KH | 21 | Takêv |
| KH | 22 | Ŏtdâr Méan Choăy |
| KH | 25 | Tbong Khmum |
| KH | 5 | Kâmpóng Spœ |
| KH | 6 | Kâmpóng Thum |
| CM | CE | Centre |
| CM | LT | Littoral |
| CM | AD | Adamaoua |
| CM | EN | Far North |
| CM | ES | Est |
| CM | NO | North |
| CM | NW | North-West |
| CM | OU | West |
| CM | SU | Sud |
| CM | SW | Sud-Ouest |
| CV | BV | Boa Vista |
| CV | BR | Brava |
| CV | MA | Maio |
| CV | MO | Mosteiros |
| CV | PA | Paul |
| CV | PN | Porto Novo |
| CV | PR | Praia |
| CV | RG | Ribeira Grande |
| CV | SL | Sal |
| CV | CA | Santa Catarina |
| CV | CR | Santa Cruz |
| CV | SD | Sao Domingos |
| CV | SF | Sao Filipe |
| CV | SV | Sao Vicente |
| CV | TA | Tarrafal |
| CV | B | Ilhas de Barlavento |
| CV | CF | Santa Catarina do Fogo |
| CV | RB | Ribeira Brava |
| CV | RS | Ribeira Grande de Santiago |
| CV | S | Ilhas de Sotavento |
| CV | SM | São Miguel |
| CV | SO | São Lourenço dos Órgãos |
| CV | SS | São Salvador do Mundo |
| CV | TS | Tarrafal de São Nicolau |
| CF | BB | Bamingui-Bangoran |
| CF | BGF | Bangui |
| CF | BK | Basse-Kotto |
| CF | HM | Haut-Mbomou |
| CF | HK | Haute-Kotto |
| CF | LB | Lobaye |
| CF | MB | Mbomou |
| CF | NM | Nana-Mambere |
| CF | UK | Ouaka |
| CF | AC | Ouham |
| CF | OP | Ouham-Pende |
| CF | VK | Vakaga |
| CF | HS | Tö-Sangä / Mbaere-Kadeï |
| CF | KB | Gribingui |
| CF | KG | Kémo-Gribingui |
| CF | MP | Ombella-Mpoko |
| CF | SE | Sangha |
| TD | BA | Batha |
| TD | CB | Chari-Baguirmi |
| TD | GR | Guera |
| TD | KA | Kanem |
| TD | LC | Lac |
| TD | LC | Logone Occidental |
| TD | LR | Logone Oriental |
| TD | MC | Moyen-Chari |
| TD | OD | Ouaddai |
| TD | SA | Salamat |
| TD | TA | Tandjile |
| TD | BG | Bahr el Ghazal |
| TD | BO | Būrkū |
| TD | EE | Inīdī ash Sharqī |
| TD | EO | Inīdī al Gharbī |
| TD | HL | Ḩajjar Lamīs |
| TD | LO | Lūghūn al Gharbī |
| TD | MA | Māndūl |
| TD | ME | Māyū Kībbī ash Sharqī |
| TD | MO | Māyū Kībbī al Gharbī |
| TD | ND | Ville de Ndjamena |
| TD | SI | Sīlā |
| TD | TI | Tibesti |
| TD | WF | Wādī Fīrā’ |
| CL | AI | Aisen del General Carlos Ibanez |
| CL | AN | Antofagasta |
| CL | AR | Araucania |
| CL | AT | Atacama |
| CL | BI | Bio-Bio |
| CL | CO | Coquimbo |
| CL | LI | Libertador General Bernardo O’Hi |
| CL | LL | Los Lagos |
| CL | MA | Magallanes y de la Antartica Chi |
| CL | ML | Maule |
| CL | RM | Region Metropolitana |
| CL | TA | Tarapaca |
| CL | VS | Valparaiso |
| CL | AP | Arica y Parinacota |
| CL | LR | Los Ríos |
| CL | NB | Ñuble |
| CN | GX | Guangxi |
| CN | GZ | Guizhou |
| CN | HA | Hainan |
| CN | HB | Hebei |
| CN | HL | Heilongjiang |
| CN | HE | Henan |
| CN | HK | Hong Kong |
| CN | HN | Hunan |
| CN | JX | Jiangxi |
| CN | JL | Jilin |
| CN | SH | Shaanxi |
| CN | SX | Shanxi |
| CN | AH | Anhui Sheng |
| CN | BJ | Beijing Shi |
| CN | CQ | Chongqing Shi |
| CN | FJ | Fujian Sheng |
| CN | GD | Guangdong Sheng |
| CN | GS | Gansu Sheng |
| CN | HI | Hainan Sheng |
| CN | JS | Jiangsu Sheng |
| CN | LN | Liaoning Sheng |
| CN | MO | Macau SAR (see also separate country code entry under MO) |
| CN | NM | Nei Mongol Zizhiqu |
| CN | NX | Ningxia Huizi Zizhiqu |
| CN | QH | Qinghai Sheng |
| CN | SC | Sichuan Sheng |
| CN | SD | Shandong Sheng |
| CN | SN | Shaanxi Sheng |
| CN | TJ | Tianjin Shi |
| CN | TW | Taiwan Sheng (see also separate country code entry under TW) |
| CN | XJ | Xinjiang Uygur Zizhiqu |
| CN | XZ | Xizang Zizhiqu |
| CN | YN | Yunnan Sheng |
| CN | ZJ | Zhejiang Sheng |
| CO | AMA | Amazonas |
| CO | ANT | Antioquia |
| CO | ARA | Arauca |
| CO | ATL | Atlantico |
| CO | BOL | Bolivar |
| CO | BOY | Boyaca |
| CO | CAL | Caldas |
| CO | CAQ | Caqueta |
| CO | CAS | Casanare |
| CO | CAU | Cauca |
| CO | CES | Cesar |
| CO | CHO | Choco |
| CO | COR | Cordoba |
| CO | CUN | Cundinamarca |
| CO | GUA | Guainia |
| CO | GUV | Guaviare |
| CO | HUI | Huila |
| CO | MAG | Magdalena |
| CO | MET | Meta |
| CO | NAR | Narino |
| CO | NSA | Norte de Santander |
| CO | PUT | Putumayo |
| CO | QUI | Quindio |
| CO | RIS | Risaralda |
| CO | SAP | San Andres y Providencia |
| CO | SAN | Santander |
| CO | SUC | Sucre |
| CO | TOL | Tolima |
| CO | VAC | Valle del Cauca |
| CO | VAU | Vaupes |
| CO | VID | Vichada |
| CO | DC | Distrito Capital de Bogotá |
| CO | LAG | La Guajira |
| KM | A | Anjouan |
| KM | G | Grande Comore |
| KM | M | Moheli |
| CG | 11 | Bouenza |
| CG | BZV | Brazzaville |
| CG | 8 | Cuvette |
| CG | 15 | Cuvette-Ouest |
| CG | 5 | Kouilou |
| CG | 2 | Lekoumou |
| CG | 7 | Likouala |
| CG | 9 | Niari |
| CG | 14 | Plateaux |
| CG | 12 | Pool |
| CG | 13 | Sangha |
| CG | 16 | Pointe-Noire |
| CD | BC | Bas-Congo |
| CD | EQ | Equateur |
| CD | KE | Kasai-Oriental |
| CD | KN | Kinshasa |
| CD | MA | Maniema |
| CD | NK | Nord-Kivu |
| CD | SK | Sud-Kivu |
| CD | BU | Bas-Uélé |
| CD | HK | Haut-Katanga |
| CD | HL | Haut-Lomami |
| CD | HU | Haut-Uélé |
| CD | IT | Ituri |
| CD | KC | Kasaï Central |
| CD | KG | Kwango |
| CD | KL | Kwilu |
| CD | KS | Kasaï |
| CD | LO | Lomami |
| CD | LU | Lualaba |
| CD | MN | Mai-Ndombe |
| CD | MO | Mongala |
| CD | NU | Nord-Ubangi |
| CD | SA | Sankuru |
| CD | SU | Sud-Ubangi |
| CD | TA | Tanganyika |
| CD | TO | Tshopo |
| CD | TU | Tshuapa |
| CR | A | Alajuela |
| CR | C | Cartago |
| CR | G | Guanacaste |
| CR | H | Heredia |
| CR | L | Limon |
| CR | P | Puntarenas |
| CR | SJ | San Jose |
| CI | AB | Abidjan |
| CI | YM | Yamoussoukro |
| CI | BS | Bas-Sassandra |
| CI | CM | Comoé |
| CI | DN | Denguélé |
| CI | GD | Gôh-Djiboua |
| CI | LC | Lacs |
| CI | LG | Lagunes |
| CI | MG | Montagnes |
| CI | SM | Sassandra-Marahoué |
| CI | SV | Savanes |
| CI | VB | Vallée du Bandama |
| CI | WR | Woroba |
| CI | ZZ | Zanzan |
| HR | 01 | Zagrebačka županija |
| HR | 02 | Krapinsko-zagorska županija |
| HR | 03 | Sisačko-moslavačka županija |
| HR | 04 | Karlovačka županija |
| HR | 05 | Varaždinska županija |
| HR | 06 | Koprivničko-križevačka županija |
| HR | 07 | Bjelovarsko-bilogorska županija |
| HR | 08 | Primorsko-goranska županija |
| HR | 09 | Ličko-senjska županija |
| HR | 10 | Virovitičko-podravska županija |
| HR | 11 | Požeško-slavonska županija |
| HR | 12 | Brodsko-posavska županija |
| HR | 13 | Zadarska županija |
| HR | 14 | Osječko-baranjska županija |
| HR | 15 | Šibensko-kninska županija |
| HR | 16 | Vukovarsko-srijemska županija |
| HR | 17 | Splitsko-dalmatinska županija |
| HR | 18 | Istarska županija |
| HR | 19 | Dubrovačko-neretvanska županija |
| HR | 20 | Međimurska županija |
| HR | 21 | Grad Zagreb |
| CU | 09 | Camaguey |
| CU | 08 | Ciego de Avila |
| CU | 06 | Cienfuegos |
| CU | 12 | Granma |
| CU | 14 | Guantanamo |
| CU | 11 | Holguin |
| CU | 99 | Isla de la Juventud |
| CU | 03 | La Habana |
| CU | 10 | Las Tunas |
| CU | 04 | Matanzas |
| CU | 01 | Pinar del Rio |
| CU | 07 | Sancti Spiritus |
| CU | 13 | Santiago de Cuba |
| CU | 05 | Villa Clara |
| CU | 15 | Artemisa |
| CU | 16 | Mayabeque |
| CY | 01 | Lefkosia |
| CY | 02 | Leymasun |
| CY | 03 | Larnaka |
| CY | 04 | Mağusa |
| CY | 05 | Pafos |
| CY | 06 | Keryneia |
| CZ | 10 | “Praha, Hlavní město” |
| CZ | 20 | Středočeský kraj |
| CZ | 201 | Benešov |
| CZ | 202 | Beroun |
| CZ | 203 | Kladno |
| CZ | 204 | Kolín |
| CZ | 205 | Kutná Hora |
| CZ | 206 | Mělník |
| CZ | 207 | Mladá Boleslav |
| CZ | 208 | Nymburk |
| CZ | 209 | Praha-východ |
| CZ | 20A | Praha-západ |
| CZ | 20B | Příbram |
| CZ | 20C | Rakovník |
| CZ | 31 | Jihočeský kraj |
| CZ | 311 | České Budějovice |
| CZ | 312 | Český Krumlov |
| CZ | 313 | Jindřichův Hradec |
| CZ | 314 | Písek |
| CZ | 315 | Prachatice |
| CZ | 316 | Strakonice |
| CZ | 317 | Tábor |
| CZ | 32 | Plzeňský kraj |
| CZ | 321 | Domažlice |
| CZ | 322 | Klatovy |
| CZ | 323 | Plzeň-město |
| CZ | 324 | Plzeň-jih |
| CZ | 325 | Plzeň-sever |
| CZ | 326 | Rokycany |
| CZ | 327 | Tachov |
| CZ | 41 | Karlovarský kraj |
| CZ | 411 | Cheb |
| CZ | 412 | Karlovy Vary |
| CZ | 413 | Sokolov |
| CZ | 42 | Ústecký kraj |
| CZ | 421 | Děčín |
| CZ | 422 | Chomutov |
| CZ | 423 | Litoměřice |
| CZ | 424 | Louny |
| CZ | 425 | Most |
| CZ | 426 | Teplice |
| CZ | 427 | Ústí nad Labem |
| CZ | 51 | Liberecký kraj |
| CZ | 511 | Česká Lípa |
| CZ | 512 | Jablonec nad Nisou |
| CZ | 513 | Liberec |
| CZ | 514 | Semily |
| CZ | 52 | Královéhradecký kraj |
| CZ | 521 | Hradec Králové |
| CZ | 522 | Jičín |
| CZ | 523 | Náchod |
| CZ | 524 | Rychnov nad Kněžnou |
| CZ | 525 | Trutnov |
| CZ | 53 | Pardubický kraj |
| CZ | 531 | Chrudim |
| CZ | 532 | Pardubice |
| CZ | 533 | Svitavy |
| CZ | 534 | Ústí nad Orlicí |
| CZ | 63 | Kraj Vysočina |
| CZ | 631 | Havlíčkův Brod |
| CZ | 632 | Jihlava |
| CZ | 633 | Pelhřimov |
| CZ | 634 | Třebíč |
| CZ | 635 | Žďár nad Sázavou |
| CZ | 64 | Jihomoravský kraj |
| CZ | 641 | Blansko |
| CZ | 642 | Brno-město |
| CZ | 643 | Brno-venkov |
| CZ | 644 | Břeclav |
| CZ | 645 | Hodonín |
| CZ | 646 | Vyškov |
| CZ | 647 | Znojmo |
| CZ | 71 | Olomoucký kraj |
| CZ | 711 | Jeseník |
| CZ | 712 | Olomouc |
| CZ | 713 | Prostějov |
| CZ | 714 | Přerov |
| CZ | 715 | Šumperk |
| CZ | 72 | Zlínský kraj |
| CZ | 721 | Kroměříž |
| CZ | 722 | Uherské Hradiště |
| CZ | 723 | Vsetín |
| CZ | 724 | Zlín |
| CZ | 80 | Moravskoslezský kraj |
| CZ | 801 | Bruntál |
| CZ | 802 | Frýdek-Místek |
| CZ | 803 | Karviná |
| CZ | 804 | Nový Jičín |
| CZ | 805 | Opava |
| CZ | 806 | Ostrava-město |
| DK | 81 | Nordjylland |
| DK | 82 | Midtjylland |
| DK | 83 | Syddanmark |
| DK | 84 | Hovedstaden |
| DK | 85 | Sjælland |
| DJ | DI | Dikhil |
| DJ | DJ | Djibouti |
| DJ | OB | Obock |
| DJ | AR | ‘Artā |
| DJ | AS | ‘Alī Şabīḩ |
| DJ | TA | Tājūrah |
| DM | 02 | Saint Andrew |
| DM | 03 | Saint David |
| DM | 04 | Saint George |
| DM | 05 | Saint John |
| DM | 06 | Saint Joseph |
| DM | 07 | Saint Luke |
| DM | 08 | Saint Mark |
| DM | 09 | Saint Patrick |
| DM | 10 | Saint Paul |
| DM | 11 | Saint Peter |
| DO | 02 | Azua |
| DO | 03 | Baoruco |
| DO | 04 | Barahona |
| DO | 05 | Dajabon |
| DO | 06 | Duarte |
| DO | 07 | Elias Pina |
| DO | 09 | Espaillat |
| DO | 30 | Hato Mayor |
| DO | 10 | Independencia |
| DO | 11 | La Altagracia |
| DO | 12 | La Romana |
| DO | 13 | La Vega |
| DO | 14 | Maria Trinidad Sanchez |
| DO | 28 | Monsenor Nouel |
| DO | 15 | Monte Cristi |
| DO | 29 | Monte Plata |
| DO | 16 | Pedernales |
| DO | 18 | Puerto Plata |
| DO | 20 | Samana |
| DO | 21 | San Cristobal |
| DO | 31 | San Jose de Ocoa |
| DO | 22 | San Juan |
| DO | 23 | San Pedro de Macoris |
| DO | 24 | Sanchez Ramirez |
| DO | 25 | Santiago |
| DO | 26 | Santiago Rodriguez |
| DO | 32 | Santo Domingo |
| DO | 27 | Valverde |
| DO | 01 | Distrito Nacional (Santo Domingo) |
| DO | 08 | El Seibo |
| DO | 17 | Peravia |
| DO | 19 | Hermanas Mirabal |
| DO | 33 | Cibao Nordeste |
| DO | 34 | Cibao Noroeste |
| DO | 35 | Cibao Norte |
| DO | 36 | Cibao Sur |
| DO | 37 | El Valle |
| DO | 38 | Enriquillo |
| DO | 39 | Higuamo |
| DO | 40 | Ozama |
| DO | 41 | Valdesia |
| DO | 42 | Yuma |
| EC | A | Azuay |
| EC | B | Bolivar |
| EC | C | Carchi |
| EC | H | Chimborazo |
| EC | X | Cotopaxi |
| EC | O | El Oro |
| EC | E | Esmeraldas |
| EC | W | Galápagos |
| EC | G | Guayas |
| EC | I | Imbabura |
| EC | L | Loja |
| EC | R | Los Rios |
| EC | M | Manabí |
| EC | S | Morona Santiago |
| EC | N | Napo |
| EC | D | Orellana |
| EC | Y | Pastaza |
| EC | P | Pichincha |
| EC | U | Sucumbíos |
| EC | T | Tungurahua |
| EC | Z | Zamora Chinchipe |
| EC | F | Cañar |
| EC | SD | Santo Domingo de los Tsáchilas |
| EC | SE | Santa Elena |
| EG | DK | Ad Daqahliyah |
| EG | BA | Al Bahr al Ahmar |
| EG | BH | Al Buhayrah |
| EG | FYM | Al Fayyum |
| EG | GH | Al Gharbiyah |
| EG | ALX | Al Iskandariyah |
| EG | IS | Al Isma’iliyah |
| EG | GZ | Al Jizah |
| EG | MNF | Al Minufiyah |
| EG | MN | Al Minya |
| EG | C | Al Qahirah |
| EG | KB | Al Qalyubiyah |
| EG | WAD | Al Wadi al Jadid |
| EG | SUZ | As Suways |
| EG | SHR | Ash Sharqiyah |
| EG | ASN | Aswan |
| EG | AST | Asyut |
| EG | BNS | Bani Suwayf |
| EG | DT | Dumyat |
| EG | JS | Janub Sina’ |
| EG | KFS | Kafr ash Shaykh |
| EG | MT | Matruh |
| EG | KN | Qina |
| EG | SIN | Shamal Sina’ |
| EG | SHG | Suhaj |
| EG | LX | Al Uqşur |
| EG | PTS | Būr Sa‘īd |
| SV | AH | Ahuachapan |
| SV | CA | Cabanas |
| SV | CH | Chalatenango |
| SV | CU | Cuscatlan |
| SV | LI | La Libertad |
| SV | PA | La Paz |
| SV | UN | La Union |
| SV | MO | Morazan |
| SV | SM | San Miguel |
| SV | SS | San Salvador |
| SV | SV | San Vicente |
| SV | SA | Santa Ana |
| SV | SO | Sonsonate |
| SV | US | Usulutan |
| GQ | AN | Provincia Annobon |
| GQ | BN | Provincia Bioko Norte |
| GQ | BS | Provincia Bioko Sur |
| GQ | CS | Provincia Centro Sur |
| GQ | KN | Provincia Kie-Ntem |
| GQ | LI | Provincia Litoral |
| GQ | WN | Provincia Wele-Nzas |
| GQ | C | Région Continentale |
| GQ | DJ | Djibloho |
| GQ | I | Región Insular |
| ER | MA | Central (Maekel) |
| ER | SK | Northern Red Sea (Semien-Keih-Bahri) |
| ER | DK | Southern Red Sea (Debub-Keih-Bahri) |
| ER | AN | ‘Anseba |
| ER | DU | Debub |
| ER | GB | Qāsh-Barkah |
| EE | 130 | Alutaguse |
| EE | 141 | Anija |
| EE | 142 | Antsla |
| EE | 171 | Elva |
| EE | 184 | Haapsalu |
| EE | 191 | Haljala |
| EE | 198 | Harku |
| EE | 205 | Hiiumaa |
| EE | 214 | Häädemeeste |
| EE | 245 | Jõelähtme |
| EE | 247 | Jõgeva |
| EE | 251 | Jõhvi |
| EE | 255 | Järva |
| EE | 272 | Kadrina |
| EE | 283 | Kambja |
| EE | 284 | Kanepi |
| EE | 291 | Kastre |
| EE | 293 | Kehtna |
| EE | 296 | Keila |
| EE | 303 | Kihnu |
| EE | 305 | Kiili |
| EE | 317 | Kohila |
| EE | 321 | Kohtla-Järve |
| EE | 338 | Kose |
| EE | 353 | Kuusalu |
| EE | 37 | Harjumaa |
| EE | 39 | Hiiumaa |
| EE | 424 | Loksa |
| EE | 430 | Lääneranna |
| EE | 431 | Lääne-Harju |
| EE | 432 | Luunja |
| EE | 441 | Lääne-Nigula |
| EE | 442 | Lüganuse |
| EE | 446 | Maardu |
| EE | 45 | Ida-Virumaa |
| EE | 478 | Muhu |
| EE | 480 | Mulgi |
| EE | 486 | Mustvee |
| EE | 50 | Jõgevamaa |
| EE | 503 | Märjamaa |
| EE | 511 | Narva |
| EE | 514 | Narva-Jõesuu |
| EE | 52 | Järvamaa |
| EE | 528 | Nõo |
| EE | 557 | Otepää |
| EE | 56 | Läänemaa |
| EE | 567 | Paide |
| EE | 586 | Peipsiääre |
| EE | 60 | Lääne-Virumaa |
| EE | 615 | Põhja-Sakala |
| EE | 618 | Põltsamaa |
| EE | 622 | Põlva |
| EE | 624 | Pärnu |
| EE | 638 | Põhja-Pärnumaa |
| EE | 64 | Põlvamaa |
| EE | 651 | Raasiku |
| EE | 653 | Rae |
| EE | 661 | Rakvere |
| EE | 663 | Rakvere |
| EE | 668 | Rapla |
| EE | 68 | Pärnumaa |
| EE | 689 | Ruhnu |
| EE | 698 | Rõuge |
| EE | 708 | Räpina |
| EE | 71 | Raplamaa |
| EE | 712 | Saarde |
| EE | 714 | Saaremaa |
| EE | 719 | Saku |
| EE | 726 | Saue |
| EE | 732 | Setomaa |
| EE | 735 | Sillamäe |
| EE | 74 | Saaremaa |
| EE | 784 | Tallinn |
| EE | 79 | Tartumaa |
| EE | 792 | Tapa |
| EE | 793 | Tartu |
| EE | 796 | Tartu |
| EE | 803 | Toila |
| EE | 809 | Tori |
| EE | 81 | Valgamaa |
| EE | 824 | Tõrva |
| EE | 834 | Türi |
| EE | 84 | Viljandimaa |
| EE | 855 | Valga |
| EE | 87 | Võrumaa |
| EE | 890 | Viimsi |
| EE | 897 | Viljandi |
| EE | 899 | Viljandi |
| EE | 901 | Vinni |
| EE | 903 | Viru-Nigula |
| EE | 907 | Vormsi |
| EE | 917 | Võru |
| EE | 919 | Võru |
| EE | 928 | Väike-Maarja |
| ET | AA | Addis Ababa |
| ET | AF | Afar |
| ET | DD | Dire Dawa |
| ET | OR | Oromia |
| ET | SO | Somali |
| ET | SN | Southern Nations - Nationalities and Peoples Region |
| ET | TI | Tigray |
| ET | AM | Āmara |
| ET | BE | Bīnshangul Gumuz |
| ET | GA | Gambela Peoples |
| ET | HA | Hārerī Hizb |
| FJ | C | Central Division |
| FJ | E | Eastern Division |
| FJ | N | Northern Division |
| FJ | R | Rotuma |
| FJ | W | Western Division |
| FJ | 01 | Ba |
| FJ | 02 | Bua |
| FJ | 03 | Cakaudrove |
| FJ | 04 | Kadavu |
| FJ | 05 | Lau |
| FJ | 06 | Lomaiviti |
| FJ | 07 | Macuata |
| FJ | 08 | Nadroga and Navosa |
| FJ | 09 | Naitasiri |
| FJ | 10 | Namosi |
| FJ | 11 | Ra |
| FJ | 12 | Rewa |
| FJ | 13 | Serua |
| FJ | 14 | Tailevu |
| FI | 01 | Landskapet Åland |
| FI | 02 | Södra Karelen |
| FI | 03 | Södra Österbotten |
| FI | 04 | Södra Savolax |
| FI | 05 | Kajanaland |
| FI | 06 | Kanta-Häme |
| FI | 07 | Mellersta Österbotten |
| FI | 08 | Mellersta Finland |
| FI | 09 | Kymmenedalen |
| FI | 10 | Lappland |
| FI | 11 | Pirkanmaa |
| FI | 12 | Pohjanmaa |
| FI | 13 | Pohjois-Karjala |
| FI | 14 | Pohjois-Pohjanmaa |
| FI | 15 | Pohjois-Savo |
| FI | 16 | Päijät-Häme |
| FI | 17 | Satakunta |
| FI | 18 | Uusimaa |
| FI | 19 | Varsinais-Suomi |
| FR | 20R | Corse |
| FR | 01 | Ain |
| FR | 02 | Aisne |
| FR | 03 | Allier |
| FR | 04 | Alpes-de-Haute-Provence |
| FR | 05 | Hautes-Alpes |
| FR | 06 | Alpes-Maritimes |
| FR | 07 | Ardèche |
| FR | 08 | Ardennes |
| FR | 09 | Ariège |
| FR | 10 | Aube |
| FR | 11 | Aude |
| FR | 12 | Aveyron |
| FR | 13 | Bouches-du-Rhône |
| FR | 14 | Calvados |
| FR | 15 | Cantal |
| FR | 16 | Charente |
| FR | 17 | Charente-Maritime |
| FR | 18 | Cher |
| FR | 19 | Corrèze |
| FR | 21 | Côte-d’Or |
| FR | 22 | Côtes-d’Armor |
| FR | 23 | Creuse |
| FR | 24 | Dordogne |
| FR | 25 | Doubs |
| FR | 26 | Drôme |
| FR | 27 | Eure |
| FR | 28 | Eure-et-Loir |
| FR | 29 | Finistère |
| FR | 2A | Corse-du-Sud |
| FR | 2B | Haute-Corse |
| FR | 30 | Gard |
| FR | 31 | Haute-Garonne |
| FR | 32 | Gers |
| FR | 33 | Gironde |
| FR | 34 | Hérault |
| FR | 35 | Ille-et-Vilaine |
| FR | 36 | Indre |
| FR | 37 | Indre-et-Loire |
| FR | 38 | Isère |
| FR | 39 | Jura |
| FR | 40 | Landes |
| FR | 41 | Loir-et-Cher |
| FR | 42 | Loire |
| FR | 43 | Haute-Loire |
| FR | 44 | Loire-Atlantique |
| FR | 45 | Loiret |
| FR | 46 | Lot |
| FR | 47 | Lot-et-Garonne |
| FR | 48 | Lozère |
| FR | 49 | Maine-et-Loire |
| FR | 50 | Manche |
| FR | 51 | Marne |
| FR | 52 | Haute-Marne |
| FR | 53 | Mayenne |
| FR | 54 | Meurthe-et-Moselle |
| FR | 55 | Meuse |
| FR | 56 | Morbihan |
| FR | 57 | Moselle |
| FR | 58 | Nièvre |
| FR | 59 | Nord |
| FR | 60 | Oise |
| FR | 61 | Orne |
| FR | 62 | Pas-de-Calais |
| FR | 63 | Puy-de-Dôme |
| FR | 64 | Pyrénées-Atlantiques |
| FR | 65 | Hautes-Pyrénées |
| FR | 66 | Pyrénées-Orientales |
| FR | 67 | Bas-Rhin |
| FR | 68 | Haut-Rhin |
| FR | 69 | Rhône |
| FR | 70 | Haute-Saône |
| FR | 71 | Saône-et-Loire |
| FR | 72 | Sarthe |
| FR | 73 | Savoie |
| FR | 74 | Haute-Savoie |
| FR | 75 | Paris |
| FR | 76 | Seine-Maritime |
| FR | 77 | Seine-et-Marne |
| FR | 78 | Yvelines |
| FR | 79 | Deux-Sèvres |
| FR | 80 | Somme |
| FR | 81 | Tarn |
| FR | 82 | Tarn-et-Garonne |
| FR | 83 | Var |
| FR | 84 | Vaucluse |
| FR | 85 | Vendée |
| FR | 86 | Vienne |
| FR | 87 | Haute-Vienne |
| FR | 88 | Vosges |
| FR | 89 | Yonne |
| FR | 90 | Territoire de Belfort |
| FR | 91 | Essonne |
| FR | 92 | Hauts-de-Seine |
| FR | 93 | Seine-Saint-Denis |
| FR | 94 | Val-de-Marne |
| FR | 95 | Val-d’Oise |
| FR | 971 | Guadeloupe |
| FR | 972 | Martinique |
| FR | 973 | Guyane (française) |
| FR | 974 | La Réunion |
| FR | 976 | Mayotte |
| FR | ARA | Auvergne-Rhône-Alpes |
| FR | BFC | Bourgogne-Franche-Comté |
| FR | BL | Saint-Barthélemy (see also separate country code entry under BL) |
| FR | BRE | Bretagne |
| FR | CP | Clipperton |
| FR | CVL | Centre-Val de Loire |
| FR | GES | Grand-Est |
| FR | GF | Guyane (française) (see also separate country code entry under GF) |
| FR | GP | Guadeloupe (see also separate country code entry under GP) |
| FR | HDF | Hauts-de-France |
| FR | IDF | Île-de-France |
| FR | MF | Saint-Martin (see also separate country code entry under MF) |
| FR | MQ | Martinique (see also separate country code entry under MQ) |
| FR | NAQ | Nouvelle-Aquitaine |
| FR | NC | Nouvelle-Calédonie (see also separate country code entry under NC) |
| FR | NOR | Normandie |
| FR | OCC | Occitanie |
| FR | PAC | Provence-Alpes-Côte-d’Azur |
| FR | PDL | Pays-de-la-Loire |
| FR | PF | Polynésie française (see also separate country code entry under PF) |
| FR | PM | Saint-Pierre-et-Miquelon (see also separate country code entry under PM) |
| FR | RE | La Réunion (see also separate country code entry under RE) |
| FR | TF | Terres australes françaises (see also separate country code entry under TF) |
| FR | WF | Wallis-et-Futuna (see also separate country code entry under WF) |
| FR | YT | Mayotte (see also separate country code entry under YT) |
| GA | 1 | Estuaire |
| GA | 2 | Haut-Ogooue |
| GA | 3 | Moyen-Ogooue |
| GA | 4 | Ngounie |
| GA | 5 | Nyanga |
| GA | 6 | Ogooue-Ivindo |
| GA | 7 | Ogooue-Lolo |
| GA | 8 | Ogooue-Maritime |
| GA | 9 | Woleu-Ntem |
| GM | B | Banjul |
| GM | M | Central River |
| GM | L | Lower River |
| GM | N | North Bank |
| GM | U | Upper River |
| GM | W | Western |
| GE | AB | Abkhazia |
| GE | AJ | Ajaria |
| GE | GU | Guria |
| GE | IM | Imereti |
| GE | KA | Kakheti |
| GE | KK | Kvemo Kartli |
| GE | MM | Mtskheta-Mtianeti |
| GE | RL | Racha Lechkhumi and Kvemo Svanet |
| GE | SZ | Samegrelo-Zemo Svaneti |
| GE | SJ | Samtskhe-Javakheti |
| GE | SK | Shida Kartli |
| GE | TB | Tbilisi |
| DE | BY | Bayern |
| DE | BE | Berlin |
| DE | BB | Brandenburg |
| DE | HB | Bremen |
| DE | HH | Hamburg |
| DE | HE | Hessen |
| DE | MV | Mecklenburg-Vorpommern |
| DE | NI | Niedersachsen |
| DE | NW | Nordrhein-Westfalen |
| DE | RP | Rheinland-Pfalz |
| DE | RP | Rhineland-Palatinate |
| DE | SL | Saarland |
| DE | SN | Sachsen |
| DE | ST | Sachsen-Anhalt |
| DE | SH | Schleswig-Holstein |
| DE | TH | Thüringen |
| DE | BW | Baden-Württemberg |
| GH | UE | Upper East Region |
| GH | UW | Upper West Region |
| GH | AA | Greater Accra |
| GH | AF | Ahafo |
| GH | AH | Ashanti |
| GH | BE | Bono East |
| GH | BO | Bono |
| GH | CP | Central |
| GH | EP | Eastern |
| GH | NE | North East |
| GH | NP | Northern |
| GH | OT | Oti |
| GH | SV | Savannah |
| GH | TV | Volta |
| GH | WN | Western North |
| GH | WP | Western |
| GR | 69 | Ágion Óros |
| GR | A | Anatolikí Makedonía kai Thráki |
| GR | B | Kentrikí Makedonía |
| GR | C | Dytikí Makedonía |
| GR | D | Ípeiros |
| GR | E | Thessalía |
| GR | F | Ionía Nísia |
| GR | G | Dytikí Elláda |
| GR | H | Stereá Elláda |
| GR | I | Attikí |
| GR | J | Pelopónnisos |
| GR | K | Vóreio Aigaío |
| GR | L | Nótio Aigaío |
| GR | M | Kríti |
| GL | AV | Avannaata Kommunia |
| GL | KU | Kommune Kujalleq |
| GL | QE | Qeqqata Kommunia |
| GL | QT | Kommune Qeqertalik |
| GL | SM | Kommuneqarfik Sermersooq |
| GD | 01 | Saint Andrew |
| GD | 02 | Saint David |
| GD | 03 | Saint George |
| GD | 04 | Saint John |
| GD | 05 | Saint Mark |
| GD | 06 | Saint Patrick |
| GD | 10 | Southern Grenadine Islands |
| GT | AV | Alta Verapaz |
| GT | BV | Baja Verapaz |
| GT | CM | Chimaltenango |
| GT | CQ | Chiquimula |
| GT | PE | El Peten |
| GT | PR | El Progreso |
| GT | QC | El Quiche |
| GT | ES | Escuintla |
| GT | GU | Guatemala |
| GT | HU | Huehuetenango |
| GT | IZ | Izabal |
| GT | JA | Jalapa |
| GT | JU | Jutiapa |
| GT | QZ | Quetzaltenango |
| GT | RE | Retalhuleu |
| GT | SA | Sacatepequez |
| GT | SM | San Marcos |
| GT | SR | Santa Rosa |
| GT | SO | Solola |
| GT | SU | Suchitepequez |
| GT | TO | Totonicapan |
| GT | ZA | Zacapa |
| GN | BE | Beyla |
| GN | BF | Boffa |
| GN | B | Boke |
| GN | C | Conakry |
| GN | CO | Coyah |
| GN | DB | Dabola |
| GN | DL | Dalaba |
| GN | DI | Dinguiraye |
| GN | DU | Dubreka |
| GN | F | Faranah |
| GN | FO | Forecariah |
| GN | FR | Fria |
| GN | GA | Gaoual |
| GN | K | Kankan |
| GN | KE | Kerouane |
| GN | D | Kindia |
| GN | KS | Kissidougou |
| GN | KB | Koubia |
| GN | KN | Koundara |
| GN | KO | Kouroussa |
| GN | L | Labe |
| GN | LE | Lelouma |
| GN | LO | Lola |
| GN | MC | Macenta |
| GN | ML | Mali |
| GN | M | Mamou |
| GN | MD | Mandiana |
| GN | N | Nzerekore |
| GN | PI | Pita |
| GN | SI | Siguiri |
| GN | TE | Telimele |
| GN | TO | Tougue |
| GN | YO | Yomou |
| GN | GU | Guékédou |
| GW | BS | Bissau Region |
| GW | BL | Bolama Region |
| GW | CA | Cacheu Region |
| GW | GA | Gabu Region |
| GW | OI | Oio Region |
| GW | QU | Quinara Region |
| GW | TO | Tombali Region |
| GW | BA | Bafatá |
| GW | BM | Biombo |
| GW | L | Leste |
| GW | N | Norte |
| GW | S | Sul |
| GY | BA | Barima-Waini |
| GY | CU | Cuyuni-Mazaruni |
| GY | DE | Demerara-Mahaica |
| GY | EB | East Berbice-Corentyne |
| GY | ES | Essequibo Islands-West Demerara |
| GY | MA | Mahaica-Berbice |
| GY | PM | Pomeroon-Supenaam |
| GY | PT | Potaro-Siparuni |
| GY | UD | Upper Demerara-Berbice |
| GY | UT | Upper Takutu-Upper Essequibo |
| HT | AR | Artibonite |
| HT | CE | Centre |
| HT | GA | Grand’Anse |
| HT | ND | Nord |
| HT | NE | Nord-Est |
| HT | NO | Nord-Ouest |
| HT | OU | Ouest |
| HT | SD | Sud |
| HT | SE | Sud-Est |
| HT | NI | Nippes |
| HN | AT | Atlantida |
| HN | CH | Choluteca |
| HN | CL | Colon |
| HN | CM | Comayagua |
| HN | CP | Copan |
| HN | CR | Cortes |
| HN | EP | El Paraiso |
| HN | FM | Francisco Morazan |
| HN | GD | Gracias a Dios |
| HN | IN | Intibuca |
| HN | IB | Islas de la Bahia (Bay Islands) |
| HN | LP | La Paz |
| HN | LE | Lempira |
| HN | OC | Ocotepeque |
| HN | OL | Olancho |
| HN | SB | Santa Barbara |
| HN | VA | Valle |
| HN | YO | Yoro |
| HU | BK | Bacs-Kiskun |
| HU | BA | Baranya |
| HU | BE | Bekes |
| HU | BC | Bekescsaba |
| HU | BZ | Borsod-Abauj-Zemplen |
| HU | BU | Budapest |
| HU | CS | Csongrad |
| HU | DE | Debrecen |
| HU | DU | Dunaujvaros |
| HU | EG | Eger |
| HU | FE | Fejer |
| HU | GY | Gyor |
| HU | GS | Gyor-Moson-Sopron |
| HU | HB | Hajdu-Bihar |
| HU | HE | Heves |
| HU | HV | Hodmezovasarhely |
| HU | JN | Jasz-Nagykun-Szolnok |
| HU | KV | Kaposvar |
| HU | KM | Kecskemet |
| HU | KE | Komarom-Esztergom |
| HU | MI | Miskolc |
| HU | NK | Nagykanizsa |
| HU | NO | Nograd |
| HU | NY | Nyiregyhaza |
| HU | PE | Pecs |
| HU | PE | Pest |
| HU | SO | Somogy |
| HU | SN | Sopron |
| HU | SZ | Szabolcs-Szatmar-Bereg |
| HU | SZ | Szeged |
| HU | SF | Szekesfehervar |
| HU | SK | Szolnok |
| HU | SH | Szombathely |
| HU | TB | Tatabanya |
| HU | TO | Tolna |
| HU | VA | Vas |
| HU | VE | Veszprem |
| HU | ZA | Zala |
| HU | ZE | Zalaegerszeg |
| HU | ER | Érd |
| HU | ST | Salgótarján |
| IS | 7 | Austurland |
| IS | 3 | Vesturland |
| IS | 1 | Höfuðborgarsvæði |
| IS | 2 | Suðurnes |
| IS | 4 | Vestfirðir |
| IS | 5 | Norðurland vestra |
| IS | 6 | Norðurland eystra |
| IS | 8 | Suðurland |
| IS | AKH | Akrahreppur |
| IS | AKN | Akraneskaupstaður |
| IS | AKU | Akureyrarbær |
| IS | ARN | Árneshreppur |
| IS | ASA | Ásahreppur |
| IS | BFJ | Borgarfjarðarhreppur |
| IS | BLA | Bláskógabyggð |
| IS | BLO | Blönduósbær |
| IS | BOG | Borgarbyggð |
| IS | BOL | Bolungarvíkurkaupstaður |
| IS | DAB | Dalabyggð |
| IS | DAV | Dalvíkurbyggð |
| IS | DJU | Djúpavogshreppur |
| IS | EOM | Eyja- og Miklaholtshreppur |
| IS | EYF | Eyjafjarðarsveit |
| IS | FJD | Fjarðabyggð |
| IS | FJL | Fjallabyggð |
| IS | FLA | Flóahreppur |
| IS | FLD | Fljótsdalshérað |
| IS | FLR | Fljótsdalshreppur |
| IS | GAR | Garðabær |
| IS | GOG | Grímsnes- og Grafningshreppur |
| IS | GRN | Grindavíkurbær |
| IS | GRU | Grundarfjarðarbær |
| IS | GRY | Grýtubakkahreppur |
| IS | HAF | Hafnarfjarðarkaupstaður |
| IS | HEL | Helgafellssveit |
| IS | HRG | Hörgársveit |
| IS | HRU | Hrunamannahreppur |
| IS | HUT | Húnavatnshreppur |
| IS | HUV | Húnaþing vestra |
| IS | HVA | Hvalfjarðarsveit |
| IS | HVE | Hveragerðisbær |
| IS | ISA | Ísafjarðarbær |
| IS | KAL | Kaldrananeshreppur |
| IS | KJO | Kjósarhreppur |
| IS | KOP | Kópavogsbær |
| IS | LAN | Langanesbyggð |
| IS | MOS | Mosfellsbær |
| IS | MYR | Mýrdalshreppur |
| IS | NOR | Norðurþing |
| IS | RGE | Rangárþing eystra |
| IS | RGY | Rangárþing ytra |
| IS | RHH | Reykhólahreppur |
| IS | RKN | Reykjanesbær |
| IS | RKV | Reykjavíkurborg |
| IS | SBH | Svalbarðshreppur |
| IS | SBT | Svalbarðsstrandarhreppur |
| IS | SDN | Suðurnesjabær |
| IS | SDV | Súðavíkurhreppur |
| IS | SEL | Seltjarnarnesbær |
| IS | SEY | Seyðisfjarðarkaupstaður |
| IS | SFA | Sveitarfélagið Árborg |
| IS | SHF | Sveitarfélagið Hornafjörður |
| IS | SKF | Skaftárhreppur |
| IS | SKG | Skagabyggð |
| IS | SKO | Skorradalshreppur |
| IS | SKU | Skútustaðahreppur |
| IS | SNF | Snæfellsbær |
| IS | SOG | Skeiða- og Gnúpverjahreppur |
| IS | SOL | Sveitarfélagið Ölfus |
| IS | SSF | Sveitarfélagið Skagafjörður |
| IS | SSS | Sveitarfélagið Skagaströnd |
| IS | STR | Strandabyggð |
| IS | STY | Stykkishólmsbær |
| IS | SVG | Sveitarfélagið Vogar |
| IS | TAL | Tálknafjarðarhreppur |
| IS | THG | Þingeyjarsveit |
| IS | TJO | Tjörneshreppur |
| IS | VEM | Vestmannaeyjabær |
| IS | VER | Vesturbyggð |
| IS | VOP | Vopnafjarðarhreppur |
| IN | AN | Andaman and Nicobar Islands |
| IN | AP | Andhra Pradesh |
| IN | AR | Arunāchal Pradesh |
| IN | AS | Assam |
| IN | CH | Chandīgarh |
| IN | CT | Chhattīsgarh |
| IN | DH | Dādra and Nagar Haveli and Damān and Diu |
| IN | GA | Goa |
| IN | HP | Himāchal Pradesh |
| IN | HR | Haryāna |
| IN | JH | Jhārkhand |
| IN | JK | Jammu and Kashmīr |
| IN | KL | Kerala |
| IN | LA | Ladākh |
| IN | LD | Lakshadweep |
| IN | MH | Mahārāshtra |
| IN | ML | Meghālaya |
| IN | MN | Manipur |
| IN | MP | Madhya Pradesh |
| IN | MZ | Mizoram |
| IN | NL | Nāgāland |
| IN | OR | Odisha |
| IN | PB | Punjab |
| IN | PY | Puducherry |
| IN | RJ | Rājasthān |
| IN | TG | Telangāna |
| IN | TN | Tamil Nādu |
| IN | UP | Uttar Pradesh |
| IN | UT | Uttarākhand |
| IN | WB | West Bengal |
| ID | AC | Aceh |
| ID | BA | Bali |
| ID | BT | Banten |
| ID | BE | Bengkulu |
| ID | GO | Gorontalo |
| ID | JK | Jakarta Raya |
| ID | JA | Jambi |
| ID | JB | Jawa Barat |
| ID | JT | Jawa Tengah |
| ID | JI | Jawa Timur |
| ID | KB | Kalimantan Barat |
| ID | KS | Kalimantan Selatan |
| ID | KT | Kalimantan Tengah |
| ID | KI | Kalimantan Timur |
| ID | BB | Kepulauan Bangka Belitung |
| ID | LA | Lampung |
| ID | ML | Maluku |
| ID | MU | Maluku Utara |
| ID | NB | Nusa Tenggara Barat |
| ID | NT | Nusa Tenggara Timur |
| ID | PP | Papua |
| ID | RI | Riau |
| ID | SN | Sulawesi Selatan |
| ID | ST | Sulawesi Tengah |
| ID | SG | Sulawesi Tenggara |
| ID | SA | Sulawesi Utara |
| ID | SB | Sumatera Barat |
| ID | SS | Sumatera Selatan |
| ID | SU | Sumatera Utara |
| ID | YO | Yogyakarta |
| ID | JW | Jawa |
| ID | KA | Kalimantan |
| ID | KR | Kepulauan Riau |
| ID | KU | Kalimantan Utara |
| ID | NU | Nusa Tenggara |
| ID | PB | Papua Barat |
| ID | SL | Sulawesi |
| ID | SM | Sumatera |
| ID | SR | Sulawesi Barat |
| IR | 24 | Ardabil |
| IR | 18 | Bushehr |
| IR | 10 | Esfahan |
| IR | 07 | Fars |
| IR | 01 | Gilan |
| IR | 27 | Golestan |
| IR | 13 | Hamadan |
| IR | 22 | Hormozgan |
| IR | 16 | Ilam |
| IR | 08 | Kerman |
| IR | 05 | Kermanshah |
| IR | 06 | Khuzestan |
| IR | 15 | Lorestan |
| IR | 00 | Markazi |
| IR | 02 | Mazandaran |
| IR | 26 | Qazvin |
| IR | 25 | Qom |
| IR | 20 | Semnan |
| IR | 23 | Tehran |
| IR | 21 | Yazd |
| IR | 19 | Zanjan |
| IR | 03 | Āz̄ārbāyjān-e Shārqī |
| IR | 04 | Āz̄ārbāyjān-e Ghārbī |
| IR | 09 | Khorāsān-e Raẕavī |
| IR | 11 | Sīstān va Balūchestān |
| IR | 12 | Kordestān |
| IR | 14 | Chahār Maḩāl va Bakhtīārī |
| IR | 17 | Kohgīlūyeh va Bowyer Aḩmad |
| IR | 28 | Khorāsān-e Shomālī |
| IR | 29 | Khorāsān-e Jonūbī |
| IR | 30 | Alborz |
| IQ | AN | Al Anbar |
| IQ | BA | Al Basrah |
| IQ | MU | Al Muthanna |
| IQ | QA | Al Qadisyah |
| IQ | NA | An Najaf |
| IQ | AR | Arbil |
| IQ | SU | As Sulaymaniyah |
| IQ | BB | Babil |
| IQ | BG | Baghdad |
| IQ | DA | Dahuk |
| IQ | DQ | Dhi Qar |
| IQ | DI | Diyala |
| IQ | MA | Maysan |
| IQ | NI | Ninawa |
| IQ | SD | Salah ad Din |
| IQ | WA | Wasit |
| IQ | KA | Karbalā’ |
| IQ | KI | Kirkūk |
| IE | CW | Carlow |
| IE | CN | Cavan |
| IE | CE | Clare |
| IE | CO | Cork |
| IE | DL | Donegal |
| IE | D | Dublin |
| IE | G | Galway |
| IE | KE | Kerry |
| IE | KE | Kildare |
| IE | KK | Kilkenny |
| IE | LS | Laois |
| IE | LM | Leitrim |
| IE | LK | Limerick |
| IE | LD | Longford |
| IE | LH | Louth |
| IE | MO | Mayo |
| IE | MH | Meath |
| IE | MO | Monaghan |
| IE | OY | Offaly |
| IE | RN | Roscommon |
| IE | SO | Sligo |
| IE | TA | Tipperary |
| IE | WD | Waterford |
| IE | WH | Westmeath |
| IE | WX | Wexford |
| IE | WW | Wicklow |
| IE | C | Connaught |
| IE | L | Leinster |
| IE | M | Munster |
| IE | U | Ulster |
| IL | HA | Haifa |
| IL | JM | Jehuda Mountains |
| IL | TA | Tel Aviv (Gosh Dan) |
| IL | D | Ha Darom |
| IL | M | Ha Merkaz |
| IL | Z | Ha Tsafon |
| IT | AG | Agrigento |
| IT | AL | Alessandria |
| IT | AN | Ancona |
| IT | AR | Arezzo |
| IT | AP | Ascoli Piceno |
| IT | AT | Asti |
| IT | AV | Avellino |
| IT | BA | Bari |
| IT | BL | Belluno |
| IT | BN | Benevento |
| IT | BG | Bergamo |
| IT | BI | Biella |
| IT | BO | Bologna |
| IT | BZ | Bolzano |
| IT | BS | Brescia |
| IT | BR | Brindisi |
| IT | CA | Cagliari |
| IT | CL | Caltanissetta |
| IT | CB | Campobasso |
| IT | CE | Caserta |
| IT | CT | Catania |
| IT | CZ | Catanzaro |
| IT | CH | Chieti |
| IT | CO | Como |
| IT | CS | Cosenza |
| IT | CR | Cremona |
| IT | KR | Crotone |
| IT | CN | Cuneo |
| IT | EN | Enna |
| IT | FE | Ferrara |
| IT | FI | Firenze |
| IT | FG | Foggia |
| IT | FC | Forli-Cesena |
| IT | FR | Frosinone |
| IT | GE | Genova |
| IT | GO | Gorizia |
| IT | GR | Grosseto |
| IT | IM | Imperia |
| IT | IS | Isernia |
| IT | AQ | L’Aquila |
| IT | SP | La Spezia |
| IT | LT | Latina |
| IT | LE | Lecce |
| IT | LC | Lecco |
| IT | LI | Livorno |
| IT | LO | Lodi |
| IT | LU | Lucca |
| IT | MC | Macerata |
| IT | MN | Mantova |
| IT | MS | Massa-Carrara |
| IT | MT | Matera |
| IT | ME | Messina |
| IT | MI | Milano |
| IT | MO | Modena |
| IT | NA | Napoli |
| IT | NO | Novara |
| IT | NU | Nuoro |
| IT | OR | Oristano |
| IT | PD | Padova |
| IT | PA | Palermo |
| IT | PR | Parma |
| IT | PV | Pavia |
| IT | PG | Perugia |
| IT | PU | Pesaro e Urbino |
| IT | PE | Pescara |
| IT | PC | Piacenza |
| IT | PI | Pisa |
| IT | PT | Pistoia |
| IT | PN | Pordenone |
| IT | PZ | Potenza |
| IT | PO | Prato |
| IT | RG | Ragusa |
| IT | RA | Ravenna |
| IT | RC | Reggio Calabria |
| IT | RE | Reggio Emilia |
| IT | RI | Rieti |
| IT | RN | Rimini |
| IT | RM | Roma |
| IT | RO | Rovigo |
| IT | SA | Salerno |
| IT | SS | Sassari |
| IT | SV | Savona |
| IT | SI | Siena |
| IT | SR | Siracusa |
| IT | SO | Sondrio |
| IT | TA | Taranto |
| IT | TE | Teramo |
| IT | TR | Terni |
| IT | TO | Torino |
| IT | TP | Trapani |
| IT | TN | Trento |
| IT | TV | Treviso |
| IT | TS | Trieste |
| IT | UD | Udine |
| IT | VA | Varese |
| IT | VE | Venezia |
| IT | VB | Verbano-Cusio-Ossola |
| IT | VC | Vercelli |
| IT | VR | Verona |
| IT | VV | Vibo Valentia |
| IT | VI | Vicenza |
| IT | VT | Viterbo |
| IT | 21 | Piemonte |
| IT | 23 | Valle d’Aosta |
| IT | 25 | Lombardia |
| IT | 32 | Trentino-Südtirol |
| IT | 34 | Veneto |
| IT | 36 | Friuli Venezia Giulia |
| IT | 42 | Liguria |
| IT | 45 | Emilia-Romagna |
| IT | 52 | Toscana |
| IT | 55 | Umbria |
| IT | 57 | Marche |
| IT | 62 | Lazio |
| IT | 65 | Abruzzo |
| IT | 67 | Molise |
| IT | 72 | Campania |
| IT | 75 | Puglia |
| IT | 77 | Basilicata |
| IT | 78 | Calabria |
| IT | 82 | Sicilia |
| IT | 88 | Sardegna |
| IT | BT | Barletta-Andria-Trani |
| IT | FM | Fermo |
| IT | MB | Monza e Brianza |
| IT | SU | Sud Sardegna |
| JM | 01 | Kingston |
| JM | 02 | Saint Andrew |
| JM | 03 | Saint Thomas |
| JM | 04 | Portland |
| JM | 05 | Saint Mary |
| JM | 06 | Saint Ann |
| JM | 07 | Trelawny |
| JM | 08 | Saint James |
| JM | 09 | Hanover |
| JM | 10 | Westmoreland |
| JM | 11 | Saint Elizabeth |
| JM | 12 | Manchester |
| JM | 13 | Clarendon |
| JM | 14 | Saint Catherine |
| JP | 23 | Aichi |
| JP | 05 | Akita |
| JP | 02 | Aomori |
| JP | 12 | Chiba |
| JP | 38 | Ehime |
| JP | 18 | Fukui |
| JP | 40 | Fukuoka |
| JP | 07 | Fukushima |
| JP | 21 | Gifu |
| JP | 34 | Hiroshima |
| JP | 01 | Hokkaido |
| JP | 28 | Hyogo |
| JP | 08 | Ibaraki |
| JP | 17 | Ishikawa |
| JP | 03 | Iwate |
| JP | 37 | Kagawa |
| JP | 46 | Kagoshima |
| JP | 14 | Kanagawa |
| JP | 39 | Kochi |
| JP | 43 | Kumamoto |
| JP | 26 | Kyoto |
| JP | 24 | Mie |
| JP | 04 | Miyagi |
| JP | 45 | Miyazaki |
| JP | 20 | Nagano |
| JP | 42 | Nagasaki |
| JP | 29 | Nara |
| JP | 15 | Niigata |
| JP | 44 | Oita |
| JP | 33 | Okayama |
| JP | 47 | Okinawa |
| JP | 27 | Osaka |
| JP | 41 | Saga |
| JP | 11 | Saitama |
| JP | 25 | Shiga |
| JP | 32 | Shimane |
| JP | 22 | Shizuoka |
| JP | 09 | Tochigi |
| JP | 36 | Tokushima |
| JP | 13 | Tokyo |
| JP | 31 | Tottori |
| JP | 16 | Toyama |
| JP | 30 | Wakayama |
| JP | 06 | Yamagata |
| JP | 35 | Yamaguchi |
| JP | 19 | Yamanashi |
| JP | 10 | Gunma |
| JO | AM | ‘Amman |
| JO | AJ | Ajlun |
| JO | KA | Al Karak |
| JO | MA | Al Mafraq |
| JO | AT | At Tafilah |
| JO | AZ | Az Zarqa’ |
| JO | IR | Irbid |
| JO | JA | Jarash |
| JO | MA | Ma’an |
| JO | MD | Madaba |
| JO | AQ | Al ‘Aqabah |
| JO | BA | Al Balqā’ |
| JO | MN | Ma‘ān |
| KZ | ALA | Almaty |
| KZ | AKM | Aqmola oblysy |
| KZ | AKT | Aqtöbe oblysy |
| KZ | ALM | Almaty oblysy |
| KZ | AST | Nur-Sultan |
| KZ | ATY | Atyrauskaya oblast’ |
| KZ | KAR | Qaraghandy oblysy |
| KZ | KUS | Qostanay oblysy |
| KZ | KZY | Qyzylorda oblysy |
| KZ | MAN | Mangystauskaja oblast’ |
| KZ | PAV | Pavlodarskaya oblast’ |
| KZ | SEV | Soltüstik Qazaqstan oblysy |
| KZ | SHY | Šimkent |
| KZ | VOS | Vostočno-Kazahstanskaja oblast’ |
| KZ | YUZ | Türkistan oblysy |
| KZ | ZAP | Zapadno-Kazakhstanskaya oblast’ |
| KZ | ZHA | Zhambylskaya oblast’ |
| KE | 01 | Baringo |
| KE | 02 | Bomet |
| KE | 03 | Bungoma |
| KE | 04 | Busia |
| KE | 05 | Elgeyo/Marakwet |
| KE | 06 | Embu |
| KE | 07 | Garissa |
| KE | 08 | Homa Bay |
| KE | 09 | Isiolo |
| KE | 10 | Kajiado |
| KE | 11 | Kakamega |
| KE | 12 | Kericho |
| KE | 13 | Kiambu |
| KE | 14 | Kilifi |
| KE | 15 | Kirinyaga |
| KE | 16 | Kisii |
| KE | 17 | Kisumu |
| KE | 18 | Kitui |
| KE | 19 | Kwale |
| KE | 20 | Laikipia |
| KE | 21 | Lamu |
| KE | 22 | Machakos |
| KE | 23 | Makueni |
| KE | 24 | Mandera |
| KE | 25 | Marsabit |
| KE | 26 | Meru |
| KE | 27 | Migori |
| KE | 28 | Mombasa |
| KE | 29 | Murang’a |
| KE | 30 | Nairobi City |
| KE | 31 | Nakuru |
| KE | 32 | Nandi |
| KE | 33 | Narok |
| KE | 34 | Nyamira |
| KE | 35 | Nyandarua |
| KE | 36 | Nyeri |
| KE | 37 | Samburu |
| KE | 38 | Siaya |
| KE | 39 | Taita/Taveta |
| KE | 40 | Tana River |
| KE | 41 | Tharaka-Nithi |
| KE | 42 | Trans Nzoia |
| KE | 43 | Turkana |
| KE | 44 | Uasin Gishu |
| KE | 45 | Vihiga |
| KE | 46 | Wajir |
| KE | 47 | West Pokot |
| KI | G | Gilbert Islands |
| KI | L | Line Islands |
| KI | P | Phoenix Islands |
| KP | 04 | Chagang-do |
| KP | 09 | Hamgyong-bukto |
| KP | 08 | Hamgyong-namdo |
| KP | 06 | Hwanghae-bukto |
| KP | 05 | Hwanghae-namdo |
| KP | 07 | Kangwon-do |
| KP | 03 | P’yongan-bukto |
| KP | 02 | P’yongan-namdo |
| KP | 01 | Phyeongyang |
| KP | 10 | Ryangkangto |
| KP | 13 | Rasǒn |
| KP | 14 | Namp’o |
| KR | 11 | Seoul-teukbyeolsi |
| KR | 26 | Busan-gwangyeoksi |
| KR | 27 | Daegu-gwangyeoksi |
| KR | 28 | Incheon-gwangyeoksi |
| KR | 29 | Gwangju-gwangyeoksi |
| KR | 30 | Daejeon-gwangyeoksi |
| KR | 31 | Ulsan-gwangyeoksi |
| KR | 41 | Gyeonggi-do |
| KR | 42 | Gangwon-do |
| KR | 43 | Chungcheongbuk-do |
| KR | 44 | Chungcheongnam-do |
| KR | 45 | Jeollabuk-do |
| KR | 46 | Jeollanam-do |
| KR | 47 | Gyeongsangbuk-do |
| KR | 48 | Gyeongsangnam-do |
| KR | 49 | Jeju-teukbyeoljachido |
| KR | 50 | Sejong |
| KW | AH | Al Ahmadi |
| KW | FA | Al Farwaniyah |
| KW | HA | Hawalli |
| KW | JA | Al Jahrā’ |
| KW | KU | Al ‘Āşimah |
| KW | MU | Mubārak al Kabīr |
| KG | B | Batken |
| KG | GB | Bishkek |
| KG | C | Chu |
| KG | J | Jalal-Abad |
| KG | N | Naryn |
| KG | O | Osh |
| KG | T | Talas |
| KG | Y | Ysyk-Kol |
| KG | GO | Osh Shaary |
| LA | AT | Attapu |
| LA | BK | Bokeo |
| LA | BL | Bolikhamxai |
| LA | CH | Champasak |
| LA | HO | Houaphan |
| LA | KH | Khammouan |
| LA | LM | Louang Namtha |
| LA | LP | Louangphabang |
| LA | OU | Oudomxai |
| LA | PH | Phongsali |
| LA | SL | Salavan |
| LA | SV | Savannakhet |
| LA | VT | Vientiane |
| LA | XA | Xaignabouli |
| LA | XS | Xaisomboun |
| LA | XE | Xekong |
| LA | XI | Xiangkhoang |
| LV | DGV | Daugavpils |
| LV | JEL | Jelgava |
| LV | JUR | Jurmala |
| LV | LPX | Liepaja |
| LV | REZ | Rezekne |
| LV | RIX | Riga |
| LV | VEN | Ventspils |
| LV | 001 | Aglonas novads |
| LV | 002 | Aizkraukles novads |
| LV | 003 | Aizputes novads |
| LV | 004 | Aknīstes novads |
| LV | 005 | Alojas novads |
| LV | 006 | Alsungas novads |
| LV | 007 | Alūksnes novads |
| LV | 008 | Amatas novads |
| LV | 009 | Apes novads |
| LV | 010 | Auces novads |
| LV | 011 | Ādažu novads |
| LV | 012 | Babītes novads |
| LV | 013 | Baldones novads |
| LV | 014 | Baltinavas novads |
| LV | 015 | Balvu novads |
| LV | 016 | Bauskas novads |
| LV | 017 | Beverīnas novads |
| LV | 018 | Brocēnu novads |
| LV | 019 | Burtnieku novads |
| LV | 020 | Carnikavas novads |
| LV | 021 | Cesvaines novads |
| LV | 022 | Cēsu novads |
| LV | 023 | Ciblas novads |
| LV | 024 | Dagdas novads |
| LV | 025 | Daugavpils novads |
| LV | 026 | Dobeles novads |
| LV | 027 | Dundagas novads |
| LV | 028 | Durbes novads |
| LV | 029 | Engures novads |
| LV | 030 | Ērgļu novads |
| LV | 031 | Garkalnes novads |
| LV | 032 | Grobiņas novads |
| LV | 033 | Gulbenes novads |
| LV | 034 | Iecavas novads |
| LV | 035 | Ikšķiles novads |
| LV | 036 | Ilūkstes novads |
| LV | 037 | Inčukalna novads |
| LV | 038 | Jaunjelgavas novads |
| LV | 039 | Jaunpiebalgas novads |
| LV | 040 | Jaunpils novads |
| LV | 041 | Jelgavas novads |
| LV | 042 | Jēkabpils novads |
| LV | 043 | Kandavas novads |
| LV | 044 | Kārsavas novads |
| LV | 045 | Kocēnu novads |
| LV | 046 | Kokneses novads |
| LV | 047 | Krāslavas novads |
| LV | 048 | Krimuldas novads |
| LV | 049 | Krustpils novads |
| LV | 050 | Kuldīgas novads |
| LV | 051 | Ķeguma novads |
| LV | 052 | Ķekavas novads |
| LV | 053 | Lielvārdes novads |
| LV | 054 | Limbažu novads |
| LV | 055 | Līgatnes novads |
| LV | 056 | Līvānu novads |
| LV | 057 | Lubānas novads |
| LV | 058 | Ludzas novads |
| LV | 059 | Madonas novads |
| LV | 060 | Mazsalacas novads |
| LV | 061 | Mālpils novads |
| LV | 062 | Mārupes novads |
| LV | 063 | Mērsraga novads |
| LV | 064 | Naukšēnu novads |
| LV | 065 | Neretas novads |
| LV | 066 | Nīcas novads |
| LV | 067 | Ogres novads |
| LV | 068 | Olaines novads |
| LV | 069 | Ozolnieku novads |
| LV | 070 | Pārgaujas novads |
| LV | 071 | Pāvilostas novads |
| LV | 072 | Pļaviņu novads |
| LV | 073 | Preiļu novads |
| LV | 074 | Priekules novads |
| LV | 075 | Priekuļu novads |
| LV | 076 | Raunas novads |
| LV | 077 | Rēzeknes novads |
| LV | 078 | Riebiņu novads |
| LV | 079 | Rojas novads |
| LV | 080 | Ropažu novads |
| LV | 081 | Rucavas novads |
| LV | 082 | Rugāju novads |
| LV | 083 | Rundāles novads |
| LV | 084 | Rūjienas novads |
| LV | 085 | Salas novads |
| LV | 086 | Salacgrīvas novads |
| LV | 087 | Salaspils novads |
| LV | 088 | Saldus novads |
| LV | 089 | Saulkrastu novads |
| LV | 090 | Sējas novads |
| LV | 091 | Siguldas novads |
| LV | 092 | Skrīveru novads |
| LV | 093 | Skrundas novads |
| LV | 094 | Smiltenes novads |
| LV | 095 | Stopiņu novads |
| LV | 096 | Strenču novads |
| LV | 097 | Talsu novads |
| LV | 098 | Tērvetes novads |
| LV | 099 | Tukuma novads |
| LV | 100 | Vaiņodes novads |
| LV | 101 | Valkas novads |
| LV | 102 | Varakļānu novads |
| LV | 103 | Vārkavas novads |
| LV | 104 | Vecpiebalgas novads |
| LV | 105 | Vecumnieku novads |
| LV | 106 | Ventspils novads |
| LV | 107 | Viesītes novads |
| LV | 108 | Viļakas novads |
| LV | 109 | Viļānu novads |
| LV | 110 | Zilupes novads |
| LV | JKB | Jēkabpils |
| LV | VMR | Valmiera |
| LB | AK | Aakkâr |
| LB | BI | Al Biqā‘ |
| LB | JA | Al Janūb |
| LB | NA | An Nabaţīyah |
| LB | AS | Ash Shimāl |
| LB | BH | Baalbek-Hermel |
| LB | BA | Beyrouth |
| LB | BI | Béqaa |
| LB | BH | B‘alabak-Al Hirmil |
| LB | JL | Jabal Lubnān |
| LB | AS | Liban-Nord |
| LB | JA | Liban-Sud |
| LB | JL | Mont-Liban |
| LB | NA | Nabatîyé |
| LS | D | Berea |
| LS | C | Leribe |
| LS | E | Mafeteng |
| LS | A | Maseru |
| LS | F | Mohale’s Hoek |
| LS | J | Mokhotlong |
| LS | H | Qacha’s Nek |
| LS | G | Quthing |
| LS | K | Thaba-Tseka |
| LS | B | Botha-Bothe |
| LR | BM | Bomi |
| LR | BG | Bong |
| LR | GB | Grand Bassa |
| LR | CM | Grand Cape Mount |
| LR | GG | Grand Gedeh |
| LR | GK | Grand Kru |
| LR | LO | Lofa |
| LR | MG | Margibi |
| LR | MY | Maryland |
| LR | MO | Montserrado |
| LR | NI | Nimba |
| LR | RI | River Cess |
| LR | SI | Sinoe |
| LR | GP | Gbarpolu |
| LR | RG | River Gee |
| LY | JA | Al Jabal al Akhdar |
| LY | JU | Al Jufrah |
| LY | KF | Al Kufrah |
| LY | NQ | An Nuqat al Khams |
| LY | ZA | Az Zawiyah |
| LY | BA | Banghazi |
| LY | DR | Darnah |
| LY | MI | Misratah |
| LY | MQ | Murzuq |
| LY | SB | Sabha |
| LY | SR | Surt |
| LY | BU | Al Buţnān |
| LY | GT | Ghāt |
| LY | JG | Al Jabal al Gharbī |
| LY | JI | Al Jafārah |
| LY | MB | Al Marqab |
| LY | MJ | Al Marj |
| LY | NL | Nālūt |
| LY | TB | Ţarābulus |
| LY | WA | Al Wāḩāt |
| LY | WD | Wādī al Ḩayāt |
| LY | WS | Wādī ash Shāţi’ |
| LI | 01 | Balzers |
| LI | 02 | Eschen |
| LI | 03 | Gamprin |
| LI | 04 | Mauren |
| LI | 05 | Planken |
| LI | 06 | Ruggell |
| LI | 07 | Schaan |
| LI | 08 | Schellenberg |
| LI | 09 | Triesen |
| LI | 10 | Triesenberg |
| LI | 11 | Vaduz |
| LT | AL | Alytus |
| LT | 16 | Kaunas |
| LT | KL | Klaipeda |
| LT | 25 | Marijampole |
| LT | 33 | Panevezys |
| LT | 44 | Siauliai |
| LT | TA | Taurage |
| LT | TE | Telsiai |
| LT | UT | Utena |
| LT | 58 | Vilnius |
| LT | 01 | Akmenė |
| LT | 02 | Alytaus miestas |
| LT | 04 | Anykščiai |
| LT | 05 | Birštono |
| LT | 06 | Biržai |
| LT | 07 | Druskininkai |
| LT | 08 | Elektrėnai |
| LT | 09 | Ignalina |
| LT | 10 | Jonava |
| LT | 11 | Joniškis |
| LT | 12 | Jurbarkas |
| LT | 13 | Kaišiadorys |
| LT | 14 | Kalvarijos |
| LT | 15 | Kauno miestas |
| LT | 17 | Kazlų Rūdos |
| LT | 18 | Kėdainiai |
| LT | 19 | Kelmė |
| LT | 20 | Klaipėdos miestas |
| LT | 22 | Kretinga |
| LT | 23 | Kupiškis |
| LT | 24 | Lazdijai |
| LT | 26 | Mažeikiai |
| LT | 27 | Molėtai |
| LT | 28 | Neringa |
| LT | 29 | Pagėgiai |
| LT | 30 | Pakruojis |
| LT | 31 | Palangos miestas |
| LT | 32 | Panevėžio miestas |
| LT | 34 | Pasvalys |
| LT | 35 | Plungė |
| LT | 36 | Prienai |
| LT | 37 | Radviliškis |
| LT | 38 | Raseiniai |
| LT | 39 | Rietavo |
| LT | 40 | Rokiškis |
| LT | 41 | Šakiai |
| LT | 42 | Šalčininkai |
| LT | 43 | Šiaulių miestas |
| LT | 45 | Šilalė |
| LT | 46 | Šilutė |
| LT | 47 | Širvintos |
| LT | 48 | Skuodas |
| LT | 49 | Švenčionys |
| LT | 52 | Trakai |
| LT | 53 | Ukmergė |
| LT | 55 | Varėna |
| LT | 56 | Vilkaviškis |
| LT | 57 | Vilniaus miestas |
| LT | 59 | Visaginas |
| LT | 60 | Zarasai |
| LT | KU | Kauno apskritis |
| LT | MR | Marijampolės apskritis |
| LT | PN | Panevėžio apskritis |
| LT | SA | Šiaulių apskritis |
| LT | VL | Vilniaus apskritis |
| LU | CA | Capellen |
| LU | CL | Clervaux |
| LU | DI | Diekirch |
| LU | EC | Echternach |
| LU | ES | Esch-sur-Alzette |
| LU | GR | Grevenmacher |
| LU | LU | Luxembourg |
| LU | ME | Mersch |
| LU | RD | Redange |
| LU | RM | Remich |
| LU | VD | Vianden |
| LU | WI | Wiltz |
| MK | 101 | Veles |
| MK | 102 | Gradsko |
| MK | 103 | Demir Kapija |
| MK | 104 | Kavadarci |
| MK | 105 | Lozovo |
| MK | 106 | Negotino |
| MK | 107 | Rosoman |
| MK | 108 | Sveti Nikole |
| MK | 109 | Čaška |
| MK | 201 | Berovo |
| MK | 202 | Vinica |
| MK | 203 | Delčevo |
| MK | 204 | Zrnovci |
| MK | 205 | Karbinci |
| MK | 206 | Kočani |
| MK | 207 | Makedonska Kamenica |
| MK | 208 | Pehčevo |
| MK | 209 | Probištip |
| MK | 210 | Češinovo-Obleševo |
| MK | 211 | Štip |
| MK | 301 | Vevčani |
| MK | 303 | Debar |
| MK | 304 | Debrca |
| MK | 307 | Kičevo |
| MK | 308 | Makedonski Brod |
| MK | 310 | Ohrid |
| MK | 311 | Plasnica |
| MK | 312 | Struga |
| MK | 313 | Centar Župa |
| MK | 401 | Bogdanci |
| MK | 402 | Bosilovo |
| MK | 403 | Valandovo |
| MK | 404 | Vasilevo |
| MK | 405 | Gevgelija |
| MK | 406 | Dojran |
| MK | 407 | Konče |
| MK | 408 | Novo Selo |
| MK | 409 | Radoviš |
| MK | 410 | Strumica |
| MK | 501 | Bitola |
| MK | 502 | Demir Hisar |
| MK | 503 | Dolneni |
| MK | 504 | Krivogaštani |
| MK | 505 | Kruševo |
| MK | 506 | Mogila |
| MK | 507 | Novaci |
| MK | 508 | Prilep |
| MK | 509 | Resen |
| MK | 601 | Bogovinje |
| MK | 602 | Brvenica |
| MK | 603 | Vrapčište |
| MK | 604 | Gostivar |
| MK | 605 | Želino |
| MK | 606 | Jegunovce |
| MK | 607 | Mavrovo i Rostuše |
| MK | 608 | Tearce |
| MK | 609 | Tetovo |
| MK | 701 | Kratovo |
| MK | 702 | Kriva Palanka |
| MK | 703 | Kumanovo |
| MK | 704 | Lipkovo |
| MK | 705 | Rankovce |
| MK | 706 | Staro Nagoričane |
| MK | 801 | Aerodrom † |
| MK | 802 | Aračinovo |
| MK | 803 | Butel † |
| MK | 804 | Gazi Baba † |
| MK | 805 | Gjorče Petrov † |
| MK | 806 | Zelenikovo |
| MK | 807 | Ilinden |
| MK | 808 | Karpoš † |
| MK | 809 | Kisela Voda † |
| MK | 810 | Petrovec |
| MK | 811 | Saraj † |
| MK | 812 | Sopište |
| MK | 813 | Studeničani |
| MK | 814 | Centar † |
| MK | 815 | Čair † |
| MK | 816 | Čučer-Sandevo |
| MK | 817 | Šuto Orizari † |
| MG | T | Antananarivo |
| MG | D | Antsiranana |
| MG | F | Fianarantsoa |
| MG | M | Mahajanga |
| MG | A | Toamasina |
| MG | U | Toliara |
| MW | BA | Balaka |
| MW | BL | Blantyre |
| MW | CK | Chikwawa |
| MW | CR | Chiradzulu |
| MW | CT | Chitipa |
| MW | DE | Dedza |
| MW | DO | Dowa |
| MW | KR | Karonga |
| MW | KS | Kasungu |
| MW | LK | Likoma |
| MW | LI | Lilongwe |
| MW | MH | Machinga |
| MW | MG | Mangochi |
| MW | MC | Mchinji |
| MW | MU | Mulanje |
| MW | MW | Mwanza |
| MW | MZ | Mzimba |
| MW | NB | Nkhata Bay |
| MW | NK | Nkhotakota |
| MW | NS | Nsanje |
| MW | NU | Ntcheu |
| MW | NI | Ntchisi |
| MW | PH | Phalombe |
| MW | RU | Rumphi |
| MW | SA | Salima |
| MW | TH | Thyolo |
| MW | ZO | Zomba |
| MW | C | Chapakati |
| MW | N | Northern Region |
| MW | NE | Neno |
| MW | S | Southern Region |
| MY | 01 | Johor |
| MY | 02 | Kedah |
| MY | 03 | Kelantan |
| MY | 04 | Melaka |
| MY | 05 | Negeri Sembilan |
| MY | 06 | Pahang |
| MY | 08 | Perak |
| MY | 09 | Perlis |
| MY | 07 | Pulau Pinang |
| MY | 12 | Sabah |
| MY | 13 | Sarawak |
| MY | 10 | Selangor |
| MY | 11 | Terengganu |
| MY | 14 | Wilayah Persekutuan Kuala Lumpur |
| MY | 15 | Wilayah Persekutuan Labuan |
| MY | 16 | Wilayah Persekutuan Putrajaya |
| MV | 01 | Addu |
| MV | 03 | Faadhippolhu |
| MV | 08 | Kolhumadulu |
| MV | 26 | Male Atoll |
| MV | 12 | Mulaku Atoll |
| MV | 00 | South Ari Atoll |
| MV | 02 | North Ari Atoll |
| MV | 04 | Felidhu Atoll |
| MV | 05 | Hahdhunmathi |
| MV | 07 | Thiladhunmathee Uthuruburi |
| MV | 13 | North Maalhosmadulu |
| MV | 14 | North Nilandhe Atoll |
| MV | 17 | South Nilandhe Atoll |
| MV | 20 | South Maalhosmadulu |
| MV | 23 | Thiladhunmathee Dhekunuburi |
| MV | 24 | North Miladhunmadulu |
| MV | 25 | South Miladhunmadulu |
| MV | 27 | North Huvadhu Atoll |
| MV | 28 | South Huvadhu Atoll |
| MV | 29 | Fuvammulah |
| MV | MLE | Male |
| ML | 7 | Gao |
| ML | 1 | Kayes |
| ML | 8 | Kidal |
| ML | 2 | Koulikoro |
| ML | 5 | Mopti |
| ML | 4 | Segou |
| ML | 3 | Sikasso |
| ML | 6 | Tombouctou |
| ML | 10 | Taoudénit |
| ML | 9 | Ménaka |
| ML | BKO | Bamako |
| MT | 01 | Attard |
| MT | 02 | Balzan |
| MT | 03 | Birgu |
| MT | 04 | Birkirkara |
| MT | 05 | Birzebbuga |
| MT | 06 | Bormla |
| MT | 07 | Dingli |
| MT | 08 | Fgura |
| MT | 09 | Floriana |
| MT | 10 | Fontana |
| MT | 11 | Gudja |
| MT | 12 | Gzira |
| MT | 19 | Iklin |
| MT | 20 | Isla |
| MT | 21 | Kalkara |
| MT | 22 | Kercem |
| MT | 23 | Kirkop |
| MT | 24 | Lija |
| MT | 25 | Luqa |
| MT | 26 | Marsa |
| MT | 27 | Marsaskala |
| MT | 28 | Marsaxlokk |
| MT | 29 | Mdina |
| MT | 31 | Mgarr |
| MT | 32 | Mosta |
| MT | 33 | Mqabba |
| MT | 34 | Msida |
| MT | 35 | Mtarfa |
| MT | 36 | Munxar |
| MT | 37 | Nadur |
| MT | 38 | Naxxar |
| MT | 39 | Paola |
| MT | 40 | Pembroke |
| MT | 41 | Pieta |
| MT | 42 | Qala |
| MT | 43 | Qormi |
| MT | 44 | Qrendi |
| MT | 47 | Safi |
| MT | 48 | San Giljan |
| MT | 49 | San Gwann |
| MT | 50 | San Lawrenz |
| MT | 52 | Sannat |
| MT | 53 | Santa Lucija |
| MT | 54 | Santa Venera |
| MT | 55 | Siggiewi |
| MT | 56 | Sliema |
| MT | 57 | Swieqi |
| MT | 59 | Tarxien |
| MT | 60 | Valletta |
| MT | 62 | Xewkija |
| MT | 64 | Zabbar |
| MT | 67 | Zejtun |
| MT | 68 | Zurrieq |
| MT | 13 | Għajnsielem |
| MT | 14 | Għarb |
| MT | 15 | Għargħur |
| MT | 16 | Għasri |
| MT | 17 | Għaxaq |
| MT | 18 | Ħamrun |
| MT | 30 | Mellieħa |
| MT | 45 | Rabat Għawdex |
| MT | 46 | Rabat Malta |
| MT | 51 | San Pawl il-Baħar |
| MT | 58 | Ta’ Xbiex |
| MT | 61 | Xagħra |
| MT | 63 | Xgħajra |
| MT | 65 | Żebbuġ Għawdex |
| MT | 66 | Żebbuġ Malta |
| MH | ALL | Ailinglaplap |
| MH | ALK | Ailuk |
| MH | ARN | Arno |
| MH | AUR | Aur |
| MH | EBO | Ebon |
| MH | JAB | Jabat |
| MH | JAL | Jaluit |
| MH | KIL | Kili |
| MH | KWA | Kwajalein |
| MH | LAE | Lae |
| MH | LIB | Lib |
| MH | LIK | Likiep |
| MH | MAJ | Majuro |
| MH | MAL | Maloelap |
| MH | MEJ | Mejit |
| MH | MIL | Mili |
| MH | NMK | Namorik |
| MH | NMU | Namu |
| MH | RON | Rongelap |
| MH | UJA | Ujae |
| MH | WTH | Wotho |
| MH | WTJ | Wotje |
| MH | ENI | Enewetak & Ujelang |
| MH | L | Ralik chain |
| MH | T | Ratak chain |
| MH | UTI | Utrōk |
| MR | 07 | Adrar |
| MR | 03 | Assaba |
| MR | 05 | Brakna |
| MR | 08 | Dakhlet Nouadhibou |
| MR | 04 | Gorgol |
| MR | 10 | Guidimaka |
| MR | 01 | Hodh Ech Chargui |
| MR | 02 | Hodh El Gharbi |
| MR | 12 | Inchiri |
| MR | 09 | Tagant |
| MR | 11 | Tiris Zemmour |
| MR | 06 | Trarza |
| MR | 13 | Nuwākshūţ al Gharbīyah |
| MR | 14 | Nuwākshūţ ash Shamālīyah |
| MR | 15 | Nuwākshūţ al Janūbīyah |
| MU | AG | Agalega Islands |
| MU | BL | Black River |
| MU | CC | Cargados Carajos Shoals (Saint Brandon Islands) |
| MU | FL | Flacq |
| MU | GP | Grand Port |
| MU | MO | Moka |
| MU | PA | Pamplemousses |
| MU | PW | Plaines Wilhems |
| MU | PL | Port Louis |
| MU | RR | Riviere du Rempart |
| MU | RO | Rodrigues |
| MU | SA | Savanne |
| MX | AGU | Aguascalientes |
| MX | BCS | Baja California Sur |
| MX | CAM | Campeche |
| MX | CHP | Chiapas |
| MX | CHH | Chihuahua |
| MX | COA | Coahuila de Zaragoza |
| MX | COL | Colima |
| MX | DUR | Durango |
| MX | GUA | Guanajuato |
| MX | GRO | Guerrero |
| MX | HID | Hidalgo |
| MX | JAL | Jalisco |
| MX | MEX | Mexico |
| MX | MIC | Michoacan de Ocampo |
| MX | MOR | Morelos |
| MX | NAY | Nayarit |
| MX | NLE | Nuevo Leon |
| MX | OAX | Oaxaca |
| MX | PUE | Puebla |
| MX | ROO | Quintana Roo |
| MX | SLP | San Luis Potosi |
| MX | SIN | Sinaloa |
| MX | SON | Sonora |
| MX | TAB | Tabasco |
| MX | TAM | Tamaulipas |
| MX | TLA | Tlaxcala |
| MX | YUC | Yucatan |
| MX | ZAC | Zacatecas |
| MX | BCN | Baja California |
| MX | CMX | Ciudad de México |
| MX | QUE | Querétaro |
| MX | VER | Veracruz de Ignacio de la Llave |
| FM | TRK | Chuuk |
| FM | KSA | Kosrae |
| FM | PNI | Pohnpei |
| FM | YAP | Yap |
| MD | BA | Balti |
| MD | CA | Cahul |
| MD | CU | Chisinau |
| MD | ED | Edinet |
| MD | GA | Gagauzia |
| MD | OR | Orhei |
| MD | SO | Soroca |
| MD | SN | Stînga Nistrului |
| MD | UN | Ungheni |
| MD | AN | Anenii Noi |
| MD | BD | Bender [Tighina] |
| MD | BR | Briceni |
| MD | BS | Basarabeasca |
| MD | CL | Călărași |
| MD | CM | Cimișlia |
| MD | CR | Criuleni |
| MD | CS | Căușeni |
| MD | CT | Cantemir |
| MD | DO | Dondușeni |
| MD | DR | Drochia |
| MD | DU | Dubăsari |
| MD | FA | Fălești |
| MD | FL | Florești |
| MD | GL | Glodeni |
| MD | HI | Hîncești |
| MD | IA | Ialoveni |
| MD | LE | Leova |
| MD | NI | Nisporeni |
| MD | OC | Ocnița |
| MD | RE | Rezina |
| MD | RI | Rîșcani |
| MD | SD | Șoldănești |
| MD | SI | Sîngerei |
| MD | ST | Strășeni |
| MD | SV | Ștefan Vodă |
| MD | TA | Taraclia |
| MD | TE | Telenești |
| MC | FO | Fontvieille |
| MC | CO | La Condamine |
| MC | MO | Monaco-Ville |
| MC | MC | Monte-Carlo |
| MC | CL | La Colle |
| MC | GA | La Gare |
| MC | JE | Jardin Exotique |
| MC | LA | Larvotto |
| MC | MA | Malbousquet |
| MC | MG | Moneghetti |
| MC | MU | Moulins |
| MC | PH | Port-Hercule |
| MC | SD | Sainte-Dévote |
| MC | SO | La Source |
| MC | SP | Spélugues |
| MC | SR | Saint-Roman |
| MC | VR | Vallon de la Rousse |
| MN | 073 | Arhangay |
| MN | 071 | Bayan-Olgiy |
| MN | 069 | Bayanhongor |
| MN | 067 | Bulgan |
| MN | 037 | Darhan uul |
| MN | 061 | Dornod |
| MN | 057 | Dzavhan |
| MN | 065 | Govi-Altay |
| MN | 064 | Govi-Sumber |
| MN | 039 | Hentiy |
| MN | 043 | Hovd |
| MN | 041 | Hovsgol |
| MN | 053 | Omnogovi |
| MN | 035 | Orhon |
| MN | 055 | Ovorhangay |
| MN | 049 | Selenge |
| MN | 051 | Suhbaatar |
| MN | 047 | Tov |
| MN | 1 | Ulanbaatar |
| MN | 046 | Uvs |
| MN | 059 | Dundgovĭ |
| MN | 063 | Dornogovĭ |
| ME | 01 | Andrijevica |
| ME | 02 | Bar |
| ME | 03 | Berane |
| ME | 04 | Bijelo Polje |
| ME | 05 | Budva |
| ME | 06 | Cetinje |
| ME | 07 | Danilovgrad |
| ME | 08 | Herceg-Novi |
| ME | 09 | Kolašin |
| ME | 10 | Kotor |
| ME | 11 | Mojkovac |
| ME | 12 | Nikšić |
| ME | 13 | Plav |
| ME | 14 | Pljevlja |
| ME | 15 | Plužine |
| ME | 16 | Podgorica |
| ME | 17 | Rožaje |
| ME | 18 | Šavnik |
| ME | 19 | Tivat |
| ME | 20 | Ulcinj |
| ME | 21 | Žabljak |
| ME | 22 | Gusinje |
| ME | 23 | Petnjica |
| ME | 24 | Tuzi |
| MA | AGD | Agadir |
| MA | HOC | Al Hoceima |
| MA | AZI | Azilal |
| MA | BEM | Beni Mellal |
| MA | BOM | Boulemane |
| MA | CAS | Casablanca |
| MA | JDI | El Jadida |
| MA | KES | El Kelaa des Sraghna |
| MA | ESM | Es Smara |
| MA | ESI | Essaouira |
| MA | FES | Fes |
| MA | FIG | Figuig |
| MA | GUE | Guelmim |
| MA | IFR | Ifrane |
| MA | KEN | Kenitra |
| MA | KHE | Khemisset |
| MA | KHN | Khenifra |
| MA | KHO | Khouribga |
| MA | LAR | Larache |
| MA | MAR | Marrakech |
| MA | MEK | Meknes |
| MA | NAD | Nador |
| MA | OUA | Ouarzazate |
| MA | OUJ | Oujda |
| MA | SAF | Safi |
| MA | SET | Settat |
| MA | SIK | Sidi Kacem |
| MA | TAO | Taounate |
| MA | TAR | Taroudannt |
| MA | TAT | Tata |
| MA | TAZ | Taza |
| MA | TET | Tetouan |
| MA | TIZ | Tiznit |
| MA | 01 | Tanger-Tétouan-Al Hoceïma |
| MA | 02 | L’Oriental |
| MA | 03 | Fès-Meknès |
| MA | 04 | Rabat-Salé-Kénitra |
| MA | 05 | Béni Mellal-Khénifra |
| MA | 06 | Casablanca-Settat |
| MA | 07 | Marrakech-Safi |
| MA | 08 | Drâa-Tafilalet |
| MA | 09 | Souss-Massa |
| MA | 10 | Guelmim-Oued Noun (EH-partial) |
| MA | 11 | Laâyoune-Sakia El Hamra (EH-partial) |
| MA | 12 | Dakhla-Oued Ed-Dahab (EH) |
| MA | AOU | Aousserd (EH) |
| MA | ASZ | Assa-Zag (EH-partial) |
| MA | BER | Berkane |
| MA | BES | Benslimane |
| MA | BOD | Boujdour (EH) |
| MA | BRR | Berrechid |
| MA | CHE | Chefchaouen |
| MA | CHI | Chichaoua |
| MA | CHT | Chtouka-Ait Baha |
| MA | DRI | Driouch |
| MA | ERR | Errachidia |
| MA | FAH | Fahs-Anjra |
| MA | FQH | Fquih Ben Salah |
| MA | GUF | Guercif |
| MA | HAJ | El Hajeb |
| MA | HAO | Al Haouz |
| MA | INE | Inezgane-Ait Melloul |
| MA | JRA | Jerada |
| MA | LAA | Laâyoune (EH) |
| MA | MDF | M’diq-Fnideq |
| MA | MED | Médiouna |
| MA | MID | Midelt |
| MA | MOH | Mohammadia |
| MA | MOU | Moulay Yacoub |
| MA | NOU | Nouaceur |
| MA | OUD | Oued Ed-Dahab (EH) |
| MA | OUZ | Ouezzane |
| MA | RAB | Rabat |
| MA | REH | Rehamna |
| MA | SAL | Salé |
| MA | SEF | Sefrou |
| MA | SIB | Sidi Bennour |
| MA | SIF | Sidi Ifni |
| MA | SIL | Sidi Slimane |
| MA | SKH | Skhirate-Témara |
| MA | TAF | Tarfaya (EH-partial) |
| MA | TAI | Taourirt |
| MA | TIN | Tinghir |
| MA | TNG | Tanger-Assilah |
| MA | TNT | Tan-Tan (EH-partial) |
| MA | YUS | Youssoufia |
| MA | ZAG | Zagora |
| MZ | P | Cabo Delgado |
| MZ | G | Gaza |
| MZ | I | Inhambane |
| MZ | B | Manica |
| MZ | MPM | Maputo |
| MZ | N | Nampula |
| MZ | A | Niassa |
| MZ | S | Sofala |
| MZ | T | Tete |
| MZ | Q | Zambezia |
| MM | 07 | Ayeyarwady |
| MM | 02 | Bago |
| MM | 03 | Magway |
| MM | 04 | Mandalay |
| MM | 01 | Sagaing |
| MM | 05 | Tanintharyi |
| MM | 06 | Yangon |
| MM | 11 | Kachin |
| MM | 12 | Kayah |
| MM | 13 | Kayin |
| MM | 14 | Chin |
| MM | 15 | Mon |
| MM | 16 | Rakhine |
| MM | 17 | Shan |
| MM | 18 | Nay Pyi Taw |
| NA | CA | Caprivi |
| NA | ER | Erongo |
| NA | HA | Hardap |
| NA | KH | Khomas |
| NA | KU | Kunene |
| NA | OW | Ohangwena |
| NA | OH | Omaheke |
| NA | OS | Omusati |
| NA | ON | Oshana |
| NA | OT | Oshikoto |
| NA | OD | Otjozondjupa |
| NA | KA | //Karas |
| NA | KE | Kavango East |
| NA | KW | Kavango West |
| NR | 01 | Aiwo |
| NR | 02 | Anabar |
| NR | 03 | Anetan |
| NR | 04 | Anibare |
| NR | 06 | Boe |
| NR | 07 | Buada |
| NR | 08 | Denigomodu |
| NR | 09 | Ewa |
| NR | 10 | Ijuw |
| NR | 11 | Meneng |
| NR | 12 | Nibok |
| NR | 13 | Uaboe |
| NR | 14 | Yaren |
| NR | 05 | Baitsi |
| NP | BA | Bagmati |
| NP | BH | Bheri |
| NP | DH | Dhawalagiri |
| NP | GA | Gandaki |
| NP | JA | Janakpur |
| NP | KA | Karnali |
| NP | KO | Kosi |
| NP | LU | Lumbini |
| NP | MA | Mahakali |
| NP | ME | Mechi |
| NP | NA | Narayani |
| NP | RA | Rapti |
| NP | SA | Sagarmatha |
| NP | SE | Seti |
| NP | 1 | Madhyamanchal |
| NP | 2 | Mid Western |
| NP | 3 | Western |
| NP | 4 | Purwanchal |
| NP | 5 | Sudur Pashchimanchal |
| NP | P1 | Province 1 |
| NP | P2 | Province 2 |
| NP | P5 | Province 5 |
| NP | P7 | Sudūr Pashchim |
| NL | DR | Drenthe |
| NL | FL | Flevoland |
| NL | FR | Friesland |
| NL | GE | Gelderland |
| NL | GR | Groningen |
| NL | LI | Limburg |
| NL | NB | Noord Brabant |
| NL | NH | Noord Holland |
| NL | OV | Overijssel |
| NL | UT | Utrecht |
| NL | ZE | Zeeland |
| NL | ZH | Zuid Holland |
| NL | AW | Aruba (see also separate country code entry under AW) |
| NL | BQ1 | Bonaire (see also separate country code entry under BQ) |
| NL | BQ2 | Saba (see also separate country code entry under BQ) |
| NL | BQ3 | Sint Eustatius (see also separate country code entry under BQ) |
| NL | CW | Curaçao (see also separate country code entry under CW) |
| NL | SX | Sint Maarten (see also separate country code entry under SX) |
| NZ | AUK | Auckland |
| NZ | BOP | Bay of Plenty |
| NZ | CAN | Canterbury |
| NZ | GIS | Gisborne |
| NZ | HKB | Hawke’s Bay |
| NZ | MWT | Manawatu-Wanganui |
| NZ | MBH | Marlborough |
| NZ | NSN | Nelson |
| NZ | NTL | Northland |
| NZ | OTA | Otago |
| NZ | STL | Southland |
| NZ | TKI | Taranaki |
| NZ | WKO | Waikato |
| NZ | WGN | Wellington |
| NZ | WTC | West Coast |
| NZ | CIT | Wharekauri |
| NZ | TAS | Tasman |
| NI | AN | Atlantico Norte |
| NI | AS | Atlantico Sur |
| NI | BO | Boaco |
| NI | CA | Carazo |
| NI | CI | Chinandega |
| NI | CO | Chontales |
| NI | ES | Esteli |
| NI | GR | Granada |
| NI | JI | Jinotega |
| NI | LE | Leon |
| NI | MD | Madriz |
| NI | MN | Managua |
| NI | MS | Masaya |
| NI | MT | Matagalpa |
| NI | NS | Nuevo Segovia |
| NI | SJ | Rio San Juan |
| NI | RI | Rivas |
| NE | 1 | Agadez |
| NE | 2 | Diffa |
| NE | 3 | Dosso |
| NE | 4 | Maradi |
| NE | 8 | Niamey |
| NE | 5 | Tahoua |
| NE | 6 | Tillaberi |
| NE | 7 | Zinder |
| NG | AB | Abia |
| NG | FC | Abuja Federal Capital Territory |
| NG | AD | Adamawa |
| NG | AK | Akwa Ibom |
| NG | AN | Anambra |
| NG | BA | Bauchi |
| NG | BY | Bayelsa |
| NG | BE | Benue |
| NG | BO | Borno |
| NG | CR | Cross River |
| NG | DE | Delta |
| NG | EB | Ebonyi |
| NG | ED | Edo |
| NG | EK | Ekiti |
| NG | EN | Enugu |
| NG | GO | Gombe |
| NG | IM | Imo |
| NG | JI | Jigawa |
| NG | KD | Kaduna |
| NG | KN | Kano |
| NG | KT | Katsina |
| NG | KE | Kebbi |
| NG | KO | Kogi |
| NG | KW | Kwara |
| NG | LA | Lagos |
| NG | NA | Nassarawa |
| NG | NI | Niger |
| NG | OG | Ogun |
| NG | ON | Ondo |
| NG | OS | Osun |
| NG | OY | Oyo |
| NG | PL | Plateau |
| NG | RI | Rivers |
| NG | SO | Sokoto |
| NG | TA | Taraba |
| NG | YO | Yobe |
| NG | ZA | Zamfara |
| NO | 18 | Nordland |
| NO | 03 | Oslo |
| NO | 11 | Rogaland |
| NO | 15 | Møre og Romsdal |
| NO | 21 | Svalbard (Arctic Region) (see also separate country code entry under SJ) |
| NO | 22 | Jan Mayen (Arctic Region) (see also separate country code entry under SJ) |
| NO | 30 | Viken |
| NO | 34 | Innlandet |
| NO | 38 | Vestfold og Telemark |
| NO | 42 | Agder |
| NO | 46 | Vestland |
| NO | 50 | Trøndelag |
| NO | 54 | Tromssan ja Finmarkun |
| OM | DA | Ad Dakhiliyah |
| OM | WU | Al Wusta |
| OM | ZA | Az Zahirah |
| OM | MA | Masqat |
| OM | MU | Musandam |
| OM | ZU | Zufar |
| OM | BJ | Janūb al Bāţinah |
| OM | BS | Shamāl al Bāţinah |
| OM | BU | Al Buraymī |
| OM | SJ | Janūb ash Sharqīyah |
| OM | SS | Shamāl ash Sharqīyah |
| PK | BA | Balochistan |
| PK | PB | Punjab |
| PK | SD | Sindh |
| PK | GB | Gilgit-Baltistan |
| PK | IS | Islamabad |
| PK | JK | Āzād Jammūñ o Kashmīr |
| PK | KP | Khyber Pakhtunkhwa |
| PW | 002 | Aimeliik |
| PW | 004 | Airai |
| PW | 010 | Angaur |
| PW | 050 | Hatohobei |
| PW | 100 | Kayangel |
| PW | 150 | Koror |
| PW | 212 | Melekeok |
| PW | 214 | Ngaraard |
| PW | 218 | Ngarchelong |
| PW | 222 | Ngardmau |
| PW | 224 | Ngatpang |
| PW | 226 | Ngchesar |
| PW | 227 | Ngeremlengui |
| PW | 228 | Ngiwal |
| PW | 350 | Peleliu |
| PW | 370 | Sonsorol |
| PS | BTH | Bethlehem |
| PS | DEB | Deir El Balah |
| PS | GZA | Ghazzah |
| PS | HBN | Hebron |
| PS | JEM | Jerusalem |
| PS | JEN | Jenin |
| PS | JRH | Jericho and Al Aghwar |
| PS | KYS | Khān Yūnis |
| PS | NBS | Nāblus |
| PS | NGZ | Shamāl Ghazzah |
| PS | QQA | Qalqīlyah |
| PS | RBH | Ramallah |
| PS | RFH | Rafaḩ |
| PS | SLT | Salfīt |
| PS | TBS | Ţūbās |
| PS | TKM | Ţūlkarm |
| PA | 1 | Bocas del Toro |
| PA | 4 | Chiriqui |
| PA | 2 | Cocle |
| PA | 3 | Colon |
| PA | 5 | Darien |
| PA | 6 | Herrera |
| PA | 7 | Los Santos |
| PA | 8 | Panama |
| PA | 9 | Veraguas |
| PA | 10 | Panamá Oeste |
| PA | EM | Emberá |
| PA | KY | Guna Yala |
| PA | NB | Ngöbe-Buglé |
| PG | NSB | Bougainville |
| PG | CPM | Central |
| PG | CPK | Chimbu |
| PG | EBR | East New Britain |
| PG | ESW | East Sepik |
| PG | EHG | Eastern Highlands |
| PG | EPW | Enga |
| PG | GPK | Gulf |
| PG | MPM | Madang |
| PG | MRL | Manus |
| PG | MBA | Milne Bay |
| PG | MPL | Morobe |
| PG | NIK | New Ireland |
| PG | NPP | Northern |
| PG | SHM | Southern Highlands |
| PG | WBK | West New Britain |
| PG | WPD | Western |
| PG | WHM | Western Highlands |
| PG | HLA | Hela |
| PG | JWK | Jiwaka |
| PG | NCD | National Capital District (Port Moresby) |
| PG | SAN | West Sepik |
| PY | 16 | Alto Paraguay |
| PY | 10 | Alto Parana |
| PY | 13 | Amambay |
| PY | ASU | Asuncion |
| PY | 19 | Boqueron |
| PY | 5 | Caaguazu |
| PY | 6 | Caazapa |
| PY | 14 | Canindeyu |
| PY | 11 | Central |
| PY | 1 | Concepcion |
| PY | 3 | Cordillera |
| PY | 4 | Guaira |
| PY | 7 | Itapua |
| PY | 8 | Misiones |
| PY | 12 | Neembucu |
| PY | 9 | Paraguari |
| PY | 15 | Presidente Hayes |
| PY | 2 | San Pedro |
| PE | AMA | Amazonas |
| PE | ANC | Ancash |
| PE | APU | Apurimac |
| PE | ARE | Arequipa |
| PE | AYA | Ayacucho |
| PE | CAJ | Cajamarca |
| PE | CUS | Cusco |
| PE | HUV | Huancavelica |
| PE | HUC | Huanuco |
| PE | ICA | Ica |
| PE | JUN | Junin |
| PE | LAL | La Libertad |
| PE | LAM | Lambayeque |
| PE | LIM | Lima |
| PE | LOR | Loreto |
| PE | MDD | Madre de Dios |
| PE | MOQ | Moquegua |
| PE | PAS | Pasco |
| PE | PIU | Piura |
| PE | PUN | Puno |
| PE | SAM | San Martin |
| PE | TAC | Tacna |
| PE | TUM | Tumbes |
| PE | UCA | Ucayali |
| PE | CAL | Qallaw |
| PE | LMA | Municipalidad Metropolitana de Lima |
| PH | ABR | Abra |
| PH | AGN | Agusan del Norte |
| PH | AGS | Agusan del Sur |
| PH | AKL | Aklan |
| PH | ALB | Albay |
| PH | ANT | Antique |
| PH | APA | Apayao |
| PH | AUR | Aurora |
| PH | BAS | Basilan |
| PH | BAN | Bataan |
| PH | BTN | Batanes |
| PH | BTG | Batangas |
| PH | BEN | Benguet |
| PH | BIL | Biliran |
| PH | BOH | Bohol |
| PH | BUK | Bukidnon |
| PH | BUL | Bulacan |
| PH | CAG | Cagayan |
| PH | CAN | Camarines Norte |
| PH | CAS | Camarines Sur |
| PH | CAM | Camiguin |
| PH | CAP | Capiz |
| PH | CAT | Catanduanes |
| PH | CAV | Cavite |
| PH | CEB | Cebu |
| PH | DAO | Davao Oriental |
| PH | DAV | Davao del Norte |
| PH | DAS | Davao del Sur |
| PH | EAS | Eastern Samar |
| PH | GUI | Guimaras |
| PH | IFU | Ifugao |
| PH | ILN | Ilocos Norte |
| PH | ILS | Ilocos Sur |
| PH | ILI | Iloilo |
| PH | ISA | Isabela |
| PH | KAL | Kalinga |
| PH | LUN | La Union |
| PH | LAG | Laguna |
| PH | LAN | Lanao del Norte |
| PH | LAS | Lanao del Sur |
| PH | LEY | Leyte |
| PH | MAG | Maguindanao |
| PH | MAD | Marinduque |
| PH | MAS | Masbate |
| PH | MDC | Mindoro Occidental |
| PH | MDR | Mindoro Oriental |
| PH | MSC | Misamis Occidental |
| PH | MSR | Misamis Oriental |
| PH | NEC | Negros Occidental |
| PH | NER | Negros Oriental |
| PH | NSA | Northern Samar |
| PH | NUE | Nueva Ecija |
| PH | NUV | Nueva Vizcaya |
| PH | PLW | Palawan |
| PH | PAM | Pampanga |
| PH | PAN | Pangasinan |
| PH | QUE | Quezon |
| PH | QUI | Quirino |
| PH | RIZ | Rizal |
| PH | ROM | Romblon |
| PH | WSA | Samar |
| PH | SAR | Sarangani |
| PH | SIG | Siquijor |
| PH | SOR | Sorsogon |
| PH | SCO | South Cotabato |
| PH | SLE | Southern Leyte |
| PH | SUK | Sultan Kudarat |
| PH | SLU | Sulu |
| PH | SUN | Surigao del Norte |
| PH | SUR | Surigao del Sur |
| PH | TAR | Tarlac |
| PH | TAW | Tawi-Tawi |
| PH | ZMB | Zambales |
| PH | ZSI | Zamboanga Sibugay |
| PH | ZAN | Zamboanga del Norte |
| PH | ZAS | Zamboanga del Sur |
| PH | 00 | Pambansang Punong Rehiyon |
| PH | 01 | Rehiyon ng Iloko |
| PH | 02 | Rehiyon ng Lambak ng Kagayan |
| PH | 03 | Rehiyon ng Gitnang Luson |
| PH | 05 | Rehiyon ng Bikol |
| PH | 06 | Western Visayas (Region VI) |
| PH | 07 | Rehiyon ng Gitnang Bisaya |
| PH | 08 | Rehiyon ng Silangang Bisaya |
| PH | 09 | Zamboanga Peninsula (Region IX) |
| PH | 10 | Rehiyon ng Hilagang Mindanaw |
| PH | 11 | Rehiyon ng Dabaw |
| PH | 12 | Soccsksargen (Region XII) |
| PH | 13 | Rehiyon ng Karaga |
| PH | 14 | Nagsasariling Rehiyon ng Muslim sa Mindanaw |
| PH | 15 | Rehiyon ng Administratibo ng Kordilyera |
| PH | 40 | Rehiyon ng Calabarzon |
| PH | 41 | Rehiyon ng Mimaropa |
| PH | COM | Davao de Oro |
| PH | DIN | Pulo ng Dinagat |
| PH | DVO | Kanlurang Dabaw |
| PH | MOU | Mountain Province |
| PH | NCO | Kotabato |
| PL | 02 | Dolnoslaskie |
| PL | 04 | Kujawsko-Pomorskie |
| PL | 06 | Lubelskie |
| PL | 08 | Lubuskie |
| PL | 14 | Mazowieckie |
| PL | 16 | Opolskie |
| PL | 18 | Podkarpackie |
| PL | 20 | Podlaskie |
| PL | 22 | Pomorskie |
| PL | 24 | Slaskie |
| PL | 26 | Swietokrzyskie |
| PL | 28 | Warminsko-Mazurskie |
| PL | 30 | Wielkopolskie |
| PL | 32 | Zachodniopomorskie |
| PL | 10 | Łódzkie |
| PL | 12 | Małopolskie |
| PT | 07 | Évora |
| PT | 01 | Aveiro |
| PT | 02 | Beja |
| PT | 03 | Braga |
| PT | 04 | Bragança |
| PT | 05 | Castelo Branco |
| PT | 06 | Coimbra |
| PT | 08 | Faro |
| PT | 09 | Guarda |
| PT | 10 | Leiria |
| PT | 11 | Lisboa |
| PT | 12 | Portalegre |
| PT | 13 | Porto |
| PT | 14 | Santarém |
| PT | 15 | Setúbal |
| PT | 16 | Viana do Castelo |
| PT | 17 | Vila Real |
| PT | 18 | Viseu |
| PT | 20 | Região Autónoma dos Açores |
| PT | 30 | Região Autónoma da Madeira |
| QA | DA | Ad Dawhah |
| QA | WA | Al Wakrah |
| QA | RA | Ar Rayyan |
| QA | MS | Madinat ash Shamal |
| QA | US | Umm Salal |
| QA | KH | Al Khawr wa adh Dhakhīrah |
| QA | SH | Ash Shīḩānīyah |
| QA | ZA | Az̧ Z̧a‘āyin |
| RO | AB | Alba |
| RO | AR | Arad |
| RO | AG | Arges |
| RO | BC | Bacau |
| RO | BH | Bihor |
| RO | BN | Bistrita-Nasaud |
| RO | BT | Botosani |
| RO | BR | Braila |
| RO | BV | Brasov |
| RO | B | Bucuresti |
| RO | BZ | Buzau |
| RO | CL | Calarasi |
| RO | CS | Caras-Severin |
| RO | CJ | Cluj |
| RO | CT | Constanta |
| RO | CV | Covasna |
| RO | DB | Dimbovita |
| RO | DJ | Dolj |
| RO | GL | Galati |
| RO | GR | Giurgiu |
| RO | GJ | Gorj |
| RO | HR | Harghita |
| RO | HD | Hunedoara |
| RO | IL | Ialomita |
| RO | IS | Iasi |
| RO | IF | Ilfov |
| RO | MM | Maramures |
| RO | MH | Mehedinti |
| RO | MS | Mures |
| RO | NT | Neamt |
| RO | OT | Olt |
| RO | PH | Prahova |
| RO | SJ | Salaj |
| RO | SM | Satu-Mare |
| RO | SB | Sibiu |
| RO | SV | Suceava |
| RO | TR | Teleorman |
| RO | TM | Timis |
| RO | TL | Tulcea |
| RO | VL | Valcea |
| RO | VS | Vaslui |
| RO | VN | Vrancea |
| RU | BA | Barnaul |
| RU | KL | Kaluga |
| RU | KO | Kostroma |
| RU | KR | Krasnodar |
| RU | KK | Kursk |
| RU | MO | Moscow |
| RU | SA | Samara |
| RU | TA | Tambov |
| RU | TY | Tyumen |
| RU | AD | “Adygeya, Respublika” |
| RU | AL | “Altay, Respublika” |
| RU | ALT | Altayskiy kray |
| RU | AMU | Amurskaya oblast’ |
| RU | ARK | Arkhangel’skaya oblast’ |
| RU | AST | Astrakhanskaya oblast’ |
| RU | BEL | Belgorodskaya oblast’ |
| RU | BRY | Bryanskaya oblast’ |
| RU | BU | “Buryatiya, Respublika” |
| RU | CE | Chechenskaya Respublika |
| RU | CHE | Chelyabinskaya oblast’ |
| RU | CHU | Čukotskij avtonomnyj okrug |
| RU | CU | Čuvašskaja Respublika |
| RU | DA | “Dagestan, Respublika” |
| RU | IN | “Ingushetiya, Respublika” |
| RU | IRK | Irkutskaya oblast’ |
| RU | IVA | Ivanovskaya oblast’ |
| RU | KAM | Kamchatskiy kray |
| RU | KB | Kabardino-Balkarskaya Respublika |
| RU | KC | Karachayevo-Cherkesskaya Respublika |
| RU | KDA | Krasnodarskiy kray |
| RU | KEM | Kemerovskaya oblast’ |
| RU | KGD | Kaliningradskaya oblast’ |
| RU | KGN | Kurganskaya oblast’ |
| RU | KHA | Khabarovskiy kray |
| RU | KHM | Khanty-Mansiyskiy avtonomnyy okrug |
| RU | KIR | Kirovskaya oblast’ |
| RU | KLU | Kalužskaja oblast’ |
| RU | KOS | Kostromskaya oblast’ |
| RU | KRS | Kurskaya oblast’ |
| RU | KYA | Krasnoyarskiy kray |
| RU | LEN | Leningradskaya oblast’ |
| RU | LIP | Lipetskaya oblast’ |
| RU | MAG | Magadanskaya oblast’ |
| RU | ME | “Mariy El, Respublika” |
| RU | MOS | Moskovskaya oblast’ |
| RU | MOW | Moskva |
| RU | MUR | Murmanskaya oblast’ |
| RU | NEN | Nenetskiy avtonomnyy okrug |
| RU | NGR | Novgorodskaya oblast’ |
| RU | NIZ | Nizhegorodskaya oblast’ |
| RU | NVS | Novosibirskaya oblast’ |
| RU | OMS | Omskaya oblast’ |
| RU | ORE | Orenburgskaya oblast’ |
| RU | ORL | Orlovskaya oblast’ |
| RU | PER | Permskiy kray |
| RU | PNZ | Penzenskaya oblast’ |
| RU | PRI | Primorskiy kray |
| RU | PSK | Pskovskaya oblast’ |
| RU | ROS | Rostovskaya oblast’ |
| RU | RYA | Ryazanskaya oblast’ |
| RU | SAK | Sakhalinskaya oblast’ |
| RU | SAM | Samarskaya oblast’ |
| RU | SAR | Saratovskaya oblast’ |
| RU | SE | “Severnaya Osetiya, Respublika” |
| RU | SMO | Smolenskaya oblast’ |
| RU | SPE | Sankt-Peterburg |
| RU | STA | Stavropol’skiy kray |
| RU | SVE | Sverdlovskaya oblast’ |
| RU | TAM | Tambovskaya oblast’ |
| RU | TOM | Tomskaya oblast’ |
| RU | TUL | Tul’skaya oblast’ |
| RU | TVE | Tverskaya oblast’ |
| RU | TYU | Tyumenskaya oblast’ |
| RU | UD | Udmurtskaya Respublika |
| RU | ULY | Ul’yanovskaya oblast’ |
| RU | VGG | Volgogradskaya oblast’ |
| RU | VLA | Vladimirskaya oblast’ |
| RU | VLG | Vologodskaya oblast’ |
| RU | VOR | Voronežskaja oblast’ |
| RU | YAN | Yamalo-Nenetskiy avtonomnyy okrug |
| RU | YAR | Yaroslavskaya oblast’ |
| RU | YEV | Yevreyskaya avtonomnaya oblast’ |
| RU | ZAB | Zabaykal’skiy kray |
| RW | 01 | Ville de Kigali |
| RW | 02 | Iburasirazuba |
| RW | 03 | Northern |
| RW | 04 | Western |
| RW | 05 | Sud |
| SH | AC | Ascension |
| SH | HL | Saint Helena |
| SH | TA | Tristan da Cunha |
| KN | 01 | Christ Church Nichola Town |
| KN | 02 | Saint Anne Sandy Point |
| KN | 03 | Saint George Basseterre |
| KN | 04 | Saint George Gingerland |
| KN | 05 | Saint James Windward |
| KN | 07 | Saint John Figtree |
| KN | 08 | Saint Mary Cayon |
| KN | 10 | Saint Paul Charlestown |
| KN | 11 | Saint Peter Basseterre |
| KN | 12 | Saint Thomas Lowland |
| KN | 13 | Saint Thomas Middle Island |
| KN | 15 | Trinity Palmetto Point |
| KN | 06 | Saint John Capisterre |
| KN | 09 | Saint Paul Capisterre |
| KN | K | Saint Kitts |
| KN | N | Nevis |
| LC | 02 | Castries |
| LC | 03 | Choiseul |
| LC | 05 | Dennery |
| LC | 07 | Laborie |
| LC | 08 | Micoud |
| LC | 10 | Soufriere |
| LC | 01 | Anse la Raye |
| LC | 06 | Gros Islet |
| LC | 11 | Vieux Fort |
| LC | 12 | Canaries |
| VC | 01 | Charlotte |
| VC | 06 | Grenadines |
| VC | 02 | Saint Andrew |
| VC | 03 | Saint David |
| VC | 04 | Saint George |
| VC | 05 | Saint Patrick |
| WS | AA | A’ana |
| WS | AL | Aiga-i-le-Tai |
| WS | AT | Atua |
| WS | FA | Fa’asaleleaga |
| WS | GE | Gaga’emauga |
| WS | GI | Gagaifomauga |
| WS | PA | Palauli |
| WS | SA | Satupa’itea |
| WS | TU | Tuamasaga |
| WS | VF | Va’a-o-Fonoti |
| WS | VS | Vaisigano |
| SM | 01 | Acquaviva |
| SM | 06 | Borgo Maggiore |
| SM | 02 | Chiesanuova |
| SM | 07 | Citta di San Marino |
| SM | 03 | Domagnano |
| SM | 04 | Faetano |
| SM | 05 | Fiorentino |
| SM | 08 | Montegiardino |
| SM | 09 | Serravalle |
| ST | P | Principe |
| ST | 01 | Água Grande |
| ST | 02 | Cantagalo |
| ST | 03 | Caué |
| ST | 04 | Lembá |
| ST | 05 | Lobata |
| ST | 06 | Mé-Zóchi |
| SA | 14 | ‘Asir |
| SA | 11 | Al Bahah |
| SA | 08 | Al Hudud ash Shamaliyah |
| SA | 12 | Al Jawf |
| SA | 05 | Al Qasim |
| SA | 01 | Ar Riyad |
| SA | 06 | Ha’il |
| SA | 10 | Najran |
| SA | 07 | Tabuk |
| SA | 02 | Makkah al Mukarramah |
| SA | 03 | Al Madīnah al Munawwarah |
| SA | 04 | Ash Sharqīyah |
| SA | 09 | Jāzān |
| SN | DK | Dakar |
| SN | DB | Diourbel |
| SN | FK | Fatick |
| SN | KA | Kaolack |
| SN | KD | Kolda |
| SN | LG | Louga |
| SN | MT | Matam |
| SN | SL | Saint-Louis |
| SN | TC | Tambacounda |
| SN | TH | Thies |
| SN | ZG | Ziguinchor |
| SN | KE | Kédougou |
| SN | SE | Sédhiou |
| RS | 00 | Beograd |
| RS | 01 | Severnobački okrug |
| RS | 02 | Srednjebanatski okrug |
| RS | 03 | Severnobanatski okrug |
| RS | 04 | Južnobanatski okrug |
| RS | 05 | Zapadnobački okrug |
| RS | 06 | Južnobački okrug |
| RS | 07 | Sremski okrug |
| RS | 08 | Mačvanski okrug |
| RS | 09 | Kolubarski okrug |
| RS | 10 | Podunavski okrug |
| RS | 11 | Braničevski okrug |
| RS | 12 | Šumadijski okrug |
| RS | 13 | Pomoravski okrug |
| RS | 14 | Borski okrug |
| RS | 15 | Zaječarski okrug |
| RS | 16 | Zlatiborski okrug |
| RS | 17 | Moravički okrug |
| RS | 18 | Raški okrug |
| RS | 19 | Rasinski okrug |
| RS | 20 | Nišavski okrug |
| RS | 21 | Toplički okrug |
| RS | 22 | Pirotski okrug |
| RS | 23 | Jablanički okrug |
| RS | 24 | Pčinjski okrug |
| RS | 25 | Kosovski okrug |
| RS | 26 | Pećki okrug |
| RS | 27 | Prizrenski okrug |
| RS | 28 | Kosovsko-Mitrovački okrug |
| RS | 29 | Kosovsko-Pomoravski okrug |
| RS | KM | Kosovo-Metohija |
| RS | VO | Vojvodina |
| SC | 02 | Anse Boileau |
| SC | 03 | Anse Etoile |
| SC | 05 | Anse Royale |
| SC | 01 | Anse aux Pins |
| SC | 06 | Baie Lazare |
| SC | 07 | Baie Sainte Anne |
| SC | 08 | Beau Vallon |
| SC | 09 | Bel Air |
| SC | 10 | Bel Ombre |
| SC | 11 | Cascade |
| SC | 12 | Glacis |
| SC | 15 | La Digue |
| SC | 16 | La Riviere Anglaise |
| SC | 17 | Mont Buxton |
| SC | 18 | Mont Fleuri |
| SC | 19 | Plaisance |
| SC | 20 | Pointe La Rue |
| SC | 21 | Port Glaud |
| SC | 22 | Saint Louis |
| SC | 23 | Takamaka |
| SC | 04 | O Kap |
| SC | 13 | Grand’Anse Mahé |
| SC | 14 | Grand’Anse Praslin |
| SC | 24 | Les Mamelles |
| SC | 25 | Ros Kaiman |
| SC | 26 | Ile Perseverance I |
| SC | 27 | Ile Perseverance II |
| SL | E | Eastern |
| SL | N | Northern |
| SL | S | Southern |
| SL | W | Western |
| SL | NW | North Western |
| SG | 01 | Central Singapore |
| SG | 02 | North East |
| SG | 03 | North West |
| SG | 04 | South East |
| SG | 05 | South West |
| SK | NI | Nitriansky |
| SK | TC | Trenčiansky |
| SK | ZI | Žilinský |
| SK | BC | Banskobystrický kraj |
| SK | BL | Bratislavský kraj |
| SK | KI | Košický kraj |
| SK | PV | Prešovský kraj |
| SK | TA | Trnavský kraj |
| SI | 001 | Ajdovščina |
| SI | 002 | Beltinci |
| SI | 003 | Bled |
| SI | 004 | Bohinj |
| SI | 005 | Borovnica |
| SI | 006 | Bovec |
| SI | 007 | Brda |
| SI | 008 | Brezovica |
| SI | 009 | Brežice |
| SI | 010 | Tišina |
| SI | 011 | Celje |
| SI | 012 | Cerklje na Gorenjskem |
| SI | 013 | Cerknica |
| SI | 014 | Cerkno |
| SI | 015 | Črenšovci |
| SI | 016 | Črna na Koroškem |
| SI | 017 | Črnomelj |
| SI | 018 | Destrnik |
| SI | 019 | Divača |
| SI | 020 | Dobrepolje |
| SI | 021 | Dobrova-Polhov Gradec |
| SI | 022 | Dol pri Ljubljani |
| SI | 023 | Domžale |
| SI | 024 | Dornava |
| SI | 025 | Dravograd |
| SI | 026 | Duplek |
| SI | 027 | Gorenja vas-Poljane |
| SI | 028 | Gorišnica |
| SI | 029 | Gornja Radgona |
| SI | 030 | Gornji Grad |
| SI | 031 | Gornji Petrovci |
| SI | 032 | Grosuplje |
| SI | 033 | Šalovci |
| SI | 034 | Hrastnik |
| SI | 035 | Hrpelje-Kozina |
| SI | 036 | Idrija |
| SI | 037 | Ig |
| SI | 038 | Ilirska Bistrica |
| SI | 039 | Ivančna Gorica |
| SI | 040 | Izola |
| SI | 041 | Jesenice |
| SI | 042 | Juršinci |
| SI | 043 | Kamnik |
| SI | 044 | Kanal |
| SI | 045 | Kidričevo |
| SI | 046 | Kobarid |
| SI | 047 | Kobilje |
| SI | 048 | Kočevje |
| SI | 049 | Komen |
| SI | 050 | Koper |
| SI | 051 | Kozje |
| SI | 052 | Kranj |
| SI | 053 | Kranjska Gora |
| SI | 054 | Krško |
| SI | 055 | Kungota |
| SI | 056 | Kuzma |
| SI | 057 | Laško |
| SI | 058 | Lenart |
| SI | 059 | Lendava |
| SI | 060 | Litija |
| SI | 061 | Ljubljana |
| SI | 062 | Ljubno |
| SI | 063 | Ljutomer |
| SI | 064 | Logatec |
| SI | 065 | Loška dolina |
| SI | 066 | Loški Potok |
| SI | 067 | Luče |
| SI | 068 | Lukovica |
| SI | 069 | Majšperk |
| SI | 070 | Maribor |
| SI | 071 | Medvode |
| SI | 072 | Mengeš |
| SI | 073 | Metlika |
| SI | 074 | Mežica |
| SI | 075 | Miren-Kostanjevica |
| SI | 076 | Mislinja |
| SI | 077 | Moravče |
| SI | 078 | Moravske Toplice |
| SI | 079 | Mozirje |
| SI | 080 | Murska Sobota |
| SI | 081 | Muta |
| SI | 082 | Naklo |
| SI | 083 | Nazarje |
| SI | 084 | Nova Gorica |
| SI | 085 | Novo Mesto |
| SI | 086 | Odranci |
| SI | 087 | Ormož |
| SI | 088 | Osilnica |
| SI | 089 | Pesnica |
| SI | 090 | Piran |
| SI | 091 | Pivka |
| SI | 092 | Podčetrtek |
| SI | 093 | Podvelka |
| SI | 094 | Postojna |
| SI | 095 | Preddvor |
| SI | 096 | Ptuj |
| SI | 097 | Puconci |
| SI | 098 | Rače-Fram |
| SI | 099 | Radeče |
| SI | 100 | Radenci |
| SI | 101 | Radlje ob Dravi |
| SI | 102 | Radovljica |
| SI | 103 | Ravne na Koroškem |
| SI | 104 | Ribnica |
| SI | 105 | Rogašovci |
| SI | 106 | Rogaška Slatina |
| SI | 107 | Rogatec |
| SI | 108 | Ruše |
| SI | 109 | Semič |
| SI | 110 | Sevnica |
| SI | 111 | Sežana |
| SI | 112 | Slovenj Gradec |
| SI | 113 | Slovenska Bistrica |
| SI | 114 | Slovenske Konjice |
| SI | 115 | Starše |
| SI | 116 | Sveti Jurij ob Ščavnici |
| SI | 117 | Šenčur |
| SI | 118 | Šentilj |
| SI | 119 | Šentjernej |
| SI | 120 | Šentjur |
| SI | 121 | Škocjan |
| SI | 122 | Škofja Loka |
| SI | 123 | Škofljica |
| SI | 124 | Šmarje pri Jelšah |
| SI | 125 | Šmartno ob Paki |
| SI | 126 | Šoštanj |
| SI | 127 | Štore |
| SI | 128 | Tolmin |
| SI | 129 | Trbovlje |
| SI | 130 | Trebnje |
| SI | 131 | Tržič |
| SI | 132 | Turnišče |
| SI | 133 | Velenje |
| SI | 134 | Velike Lašče |
| SI | 135 | Videm |
| SI | 136 | Vipava |
| SI | 137 | Vitanje |
| SI | 138 | Vodice |
| SI | 139 | Vojnik |
| SI | 140 | Vrhnika |
| SI | 141 | Vuzenica |
| SI | 142 | Zagorje ob Savi |
| SI | 143 | Zavrč |
| SI | 144 | Zreče |
| SI | 146 | Železniki |
| SI | 147 | Žiri |
| SI | 148 | Benedikt |
| SI | 149 | Bistrica ob Sotli |
| SI | 150 | Bloke |
| SI | 151 | Braslovče |
| SI | 152 | Cankova |
| SI | 153 | Cerkvenjak |
| SI | 154 | Dobje |
| SI | 155 | Dobrna |
| SI | 156 | Dobrovnik |
| SI | 157 | Dolenjske Toplice |
| SI | 158 | Grad |
| SI | 159 | Hajdina |
| SI | 160 | Hoče-Slivnica |
| SI | 161 | Hodoš |
| SI | 162 | Horjul |
| SI | 163 | Jezersko |
| SI | 164 | Komenda |
| SI | 165 | Kostel |
| SI | 166 | Križevci |
| SI | 167 | Lovrenc na Pohorju |
| SI | 168 | Markovci |
| SI | 169 | Miklavž na Dravskem polju |
| SI | 170 | Mirna Peč |
| SI | 171 | Oplotnica |
| SI | 172 | Podlehnik |
| SI | 173 | Polzela |
| SI | 174 | Prebold |
| SI | 175 | Prevalje |
| SI | 176 | Razkrižje |
| SI | 177 | Ribnica na Pohorju |
| SI | 178 | Selnica ob Dravi |
| SI | 179 | Sodražica |
| SI | 180 | Solčava |
| SI | 181 | Sveta Ana |
| SI | 182 | Sveti Andraž v Slovenskih goricah |
| SI | 183 | Šempeter-Vrtojba |
| SI | 184 | Tabor |
| SI | 185 | Trnovska Vas |
| SI | 186 | Trzin |
| SI | 187 | Velika Polana |
| SI | 188 | Veržej |
| SI | 189 | Vransko |
| SI | 190 | Žalec |
| SI | 191 | Žetale |
| SI | 192 | Žirovnica |
| SI | 193 | Žužemberk |
| SI | 194 | Šmartno pri Litiji |
| SI | 195 | Apače |
| SI | 196 | Cirkulane |
| SI | 197 | Kosanjevica na Krki |
| SI | 198 | Makole |
| SI | 199 | Mokronog-Trebelno |
| SI | 200 | Poljčane |
| SI | 201 | Renče-Vogrsko |
| SI | 202 | Središče ob Dravi |
| SI | 203 | Straža |
| SI | 204 | Sveta Trojica v Slovenskih goricah |
| SI | 205 | Sveti Tomaž |
| SI | 206 | Šmarješke Toplice |
| SI | 207 | Gorje |
| SI | 208 | Log-Dragomer |
| SI | 209 | Rečica ob Savinji |
| SI | 210 | Sveti Jurij v Slovenskih goricah |
| SI | 211 | Šentrupert |
| SI | 212 | Mirna |
| SI | 213 | Ankaran |
| SB | CE | Central |
| SB | CH | Choiseul |
| SB | GU | Guadalcanal |
| SB | IS | Isabel |
| SB | MK | Makira |
| SB | ML | Malaita |
| SB | RB | Rennell and Bellona |
| SB | TE | Temotu |
| SB | WE | Western |
| SB | CT | Capital Territory (Honiara) |
| SO | AW | Awdal |
| SO | BK | Bakool |
| SO | BN | Banaadir |
| SO | BR | Bari |
| SO | BY | Bay |
| SO | GA | Galguduud |
| SO | GE | Gedo |
| SO | HI | Hiiraan |
| SO | JD | Jubbada Dhexe |
| SO | JH | Jubbada Hoose |
| SO | MU | Mudug |
| SO | NU | Nugaal |
| SO | SA | Sanaag |
| SO | SD | Shabeellaha Dhexe |
| SO | SH | Shabeellaha Hoose |
| SO | SO | Sool |
| SO | TO | Togdheer |
| SO | WO | Woqooyi Galbeed |
| ZA | EC | Eastern Cape |
| ZA | FS | Free State |
| ZA | GP | Gauteng |
| ZA | KZN | Kwa Zulu-Natal |
| ZA | LP | Limpopo |
| ZA | MP | Mpumalanga |
| ZA | NW | North West |
| ZA | NC | Northern Cape |
| ZA | WC | Western Cape |
| ES | AL | Álava |
| ES | AV | Ávila |
| ES | AB | Albacete |
| ES | A | Alicante |
| ES | AL | Almeria |
| ES | AS | Asturias |
| ES | BA | Badajoz |
| ES | IB | Baleares |
| ES | BA | Barcelona |
| ES | BU | Burgos |
| ES | CC | Cáceres |
| ES | CA | Cádiz |
| ES | CO | Córdoba |
| ES | CB | Cantabria |
| ES | CL | Castellón |
| ES | CE | Ceuta |
| ES | CR | Ciudad Real |
| ES | CU | Cuenca |
| ES | GI | Girona |
| ES | GR | Granada |
| ES | GU | Guadalajara |
| ES | H | Huelva |
| ES | HU | Huesca |
| ES | J | Jaén |
| ES | CA | La Coruña |
| ES | RI | La Rioja |
| ES | GC | Las Palmas |
| ES | LE | Leon |
| ES | MD | Madrid |
| ES | MA | Malaga |
| ES | ML | Melilla |
| ES | MU | Murcia |
| ES | NA | Navarra |
| ES | P | Palencia |
| ES | PO | Pontevedra |
| ES | SA | Salamanca |
| ES | TF | Santa Cruz de Tenerife |
| ES | SG | Segovia |
| ES | SE | Sevilla |
| ES | SO | Soria |
| ES | TE | Teruel |
| ES | TO | Toledo |
| ES | VC | Valencia |
| ES | VA | Valladolid |
| ES | ZA | Zamora |
| ES | Z | Zaragoza |
| ES | AN | Andalucía |
| ES | AR | Aragón |
| ES | B | Barcelona [Barcelona] |
| ES | BI | Bizkaia |
| ES | C | A Coruña [La Coruña] |
| ES | CM | Castilla-La Mancha |
| ES | CN | Canarias |
| ES | EX | Extremadura |
| ES | GA | Galicia [Galicia] |
| ES | L | Lleida [Lérida] |
| ES | LU | Lugo [Lugo] |
| ES | MC | “Murcia, Región de” |
| ES | NC | “Navarra, Comunidad Foral de” |
| ES | OR | Ourense [Orense] |
| ES | PV | País Vasco |
| ES | SS | Gipuzkoa |
| ES | T | Tarragona [Tarragona] |
| LK | 1 | Western Province |
| LK | 11 | Kŏl̮umpu |
| LK | 12 | Kampahā |
| LK | 13 | Kaḷuttuṟai |
| LK | 2 | Mattiya mākāṇam |
| LK | 21 | Mahanuvara |
| LK | 22 | Māttaḷai |
| LK | 23 | Nuwara Eliya |
| LK | 3 | Tĕṉ mākāṇam |
| LK | 31 | Kāli |
| LK | 32 | Māttaṛai |
| LK | 33 | Hambantota |
| LK | 4 | Vaṭakku mākāṇam |
| LK | 41 | Yāpanaya |
| LK | 42 | Kilinochchi |
| LK | 43 | Mannārama |
| LK | 44 | Vavuniyāva |
| LK | 45 | Mullaittivu |
| LK | 5 | Næ̆gĕnahira paḷāta |
| LK | 51 | Maṭṭakkaḷappu |
| LK | 52 | Ampāṟai |
| LK | 53 | Trincomalee |
| LK | 6 | Vayamba paḷāta |
| LK | 61 | Kuruṇægala |
| LK | 62 | Puttalama |
| LK | 7 | Vaṭamattiya mākāṇam |
| LK | 71 | Anurātapuram |
| LK | 72 | Polonnaruwa |
| LK | 8 | Uva Province |
| LK | 81 | Patuḷai |
| LK | 82 | Mŏṉarākalai |
| LK | 9 | Sabaragamuwa Province |
| LK | 91 | Ratnapura |
| LK | 92 | Kægalla |
| SD | RS | Al Bahr al Ahmar |
| SD | GZ | Al Jazirah |
| SD | KH | Al Khartum |
| SD | GD | Al Qadarif |
| SD | NW | An Nil al Abyad |
| SD | NB | An Nil al Azraq |
| SD | NO | Ash Shamaliyah |
| SD | DW | Gharb Darfur |
| SD | GK | Gharb Kurdufan |
| SD | DS | Janub Darfur |
| SD | KS | Janub Kurdufan |
| SD | KA | Kassala |
| SD | NR | Nahr an Nil |
| SD | DN | Shamal Darfur |
| SD | KN | Shamal Kurdufan |
| SD | SI | Sinnar |
| SD | DC | Wasaţ Dārfūr |
| SD | DE | Sharq Dārfūr |
| SR | BR | Brokopondo |
| SR | CM | Commewijne |
| SR | CR | Coronie |
| SR | MA | Marowijne |
| SR | NI | Nickerie |
| SR | PR | Para |
| SR | PM | Paramaribo |
| SR | SA | Saramacca |
| SR | SI | Sipaliwini |
| SR | WA | Wanica |
| SZ | HH | Hhohho |
| SZ | LU | Lubombo |
| SZ | MA | Manzini |
| SZ | SH | Shiselweni |
| SE | T | Örebro |
| SE | E | Östergötland |
| SE | K | Blekinge |
| SE | W | Dalama |
| SE | X | Gävleborg |
| SE | I | Gotland |
| SE | N | Halland |
| SE | Z | Jämtland |
| SE | F | Jönköping |
| SE | H | Kalmar |
| SE | G | Kronoberg |
| SE | BD | Norrbotten |
| SE | D | Södermanland |
| SE | M | Skåne |
| SE | AB | Stockholm |
| SE | C | Uppsala |
| SE | S | Värmland |
| SE | AC | Västerbotten |
| SE | Y | Västernorrland |
| SE | U | Västmanland |
| SE | O | Västra Götaland |
| CH | AG | Aargau |
| CH | AR | Appenzell Ausserrhoden |
| CH | AI | Appenzell Innerrhoden |
| CH | BL | Basel-Landschaft |
| CH | BS | Basel-Stadt |
| CH | BE | Bern |
| CH | FR | Fribourg |
| CH | GE | Genève |
| CH | GL | Glarus |
| CH | GR | Graubünden |
| CH | JU | Jura |
| CH | LU | Luzern |
| CH | NE | Neuchâtel |
| CH | NW | Nidwald |
| CH | OW | Obwald |
| CH | SH | Schaffhausen |
| CH | SZ | Schwyz |
| CH | SO | Solothurn |
| CH | SG | St. Gallen |
| CH | TG | Thurgau |
| CH | TI | Ticino |
| CH | UR | Uri |
| CH | VS | Valais |
| CH | VD | Vaud |
| CH | ZH | Zürich |
| CH | ZG | Zug |
| SY | HA | Al Hasakah |
| SY | LA | Al Ladhiqiyah |
| SY | QU | Al Qunaytirah |
| SY | RA | Ar Raqqah |
| SY | SU | As Suwayda |
| SY | DY | Dayr az Zawr |
| SY | DI | Dimashq |
| SY | HL | Halab |
| SY | HM | Hamah |
| SY | HI | Hims |
| SY | ID | Idlib |
| SY | RD | Rif Dimashq |
| SY | TA | Tartus |
| SY | DR | Dar’ā |
| TW | CHA | Changhua |
| TW | CYI | Chiayi |
| TW | CYQ | Chiayi |
| TW | HSQ | Hsinchu |
| TW | HSZ | Hsinchu |
| TW | HUA | Hualien |
| TW | ILA | Yilan |
| TW | KEE | Keelung |
| TW | KHH | Kaohsiung |
| TW | KIN | Kinmen |
| TW | LIE | Lienchiang |
| TW | MIA | Miaoli |
| TW | NAN | Nantou |
| TW | NWT | New Taipei |
| TW | PEN | Penghu |
| TW | PIF | Pingtung |
| TW | TAO | Taoyuan |
| TW | TNN | Tainan |
| TW | TPE | Taipei |
| TW | TTT | Taitung |
| TW | TXG | Taichung |
| TW | YUN | Yunlin |
| TJ | GB | Gorno-Badakhstan |
| TJ | KT | Khatlon |
| TJ | SU | Sughd |
| TJ | DU | Dushanbe |
| TJ | RA | nohiyahoi tobei jumhurí |
| TZ | 01 | Arusha |
| TZ | 02 | Dar es Salaam |
| TZ | 03 | Dodoma |
| TZ | 04 | Iringa |
| TZ | 05 | Kagera |
| TZ | 08 | Kigoma |
| TZ | 09 | Kilimanjaro |
| TZ | 12 | Lindi |
| TZ | 26 | Manyara |
| TZ | 13 | Mara |
| TZ | 14 | Mbeya |
| TZ | 16 | Morogoro |
| TZ | 17 | Mtwara |
| TZ | 18 | Mwanza |
| TZ | 06 | Pemba North |
| TZ | 10 | Pemba South |
| TZ | 19 | Pwani |
| TZ | 20 | Rukwa |
| TZ | 21 | Ruvuma |
| TZ | 22 | Shinyanga |
| TZ | 23 | Singida |
| TZ | 24 | Tabora |
| TZ | 25 | Tanga |
| TZ | 07 | Zanzibar North |
| TZ | 11 | Zanzibar South |
| TZ | 15 | Zanzibar West |
| TZ | 27 | Geita |
| TZ | 28 | Katavi |
| TZ | 29 | Njombe |
| TZ | 30 | Simiyu |
| TZ | 31 | Songwe |
| TH | 37 | Amnat Charoen |
| TH | 15 | Ang Thong |
| TH | 14 | Ayutthaya |
| TH | 10 | Bangkok |
| TH | 31 | Buriram |
| TH | 24 | Chachoengsao |
| TH | 18 | Chai Nat |
| TH | 36 | Chaiyaphum |
| TH | 22 | Chanthaburi |
| TH | 50 | Chiang Mai |
| TH | 57 | Chiang Rai |
| TH | 20 | Chon Buri |
| TH | 86 | Chumphon |
| TH | 46 | Kalasin |
| TH | 62 | Kamphaeng Phet |
| TH | 71 | Kanchanaburi |
| TH | 40 | Khon Kaen |
| TH | 81 | Krabi |
| TH | 52 | Lampang |
| TH | 51 | Lamphun |
| TH | 42 | Loei |
| TH | 16 | Lop Buri |
| TH | 58 | Mae Hong Son |
| TH | 44 | Maha Sarakham |
| TH | 49 | Mukdahan |
| TH | 26 | Nakhon Nayok |
| TH | 73 | Nakhon Pathom |
| TH | 48 | Nakhon Phanom |
| TH | 30 | Nakhon Ratchasima |
| TH | 60 | Nakhon Sawan |
| TH | 80 | Nakhon Si Thammarat |
| TH | 55 | Nan |
| TH | 96 | Narathiwat |
| TH | 39 | Nong Bua Lamphu |
| TH | 43 | Nong Khai |
| TH | 12 | Nonthaburi |
| TH | 13 | Pathum Thani |
| TH | 94 | Pattani |
| TH | 82 | Phangnga |
| TH | 93 | Phatthalung |
| TH | 56 | Phayao |
| TH | 67 | Phetchabun |
| TH | 76 | Phetchaburi |
| TH | 66 | Phichit |
| TH | 65 | Phitsanulok |
| TH | 54 | Phrae |
| TH | 83 | Phuket |
| TH | 25 | Prachin Buri |
| TH | 77 | Prachuap Khiri Khan |
| TH | 85 | Ranong |
| TH | 70 | Ratchaburi |
| TH | 21 | Rayong |
| TH | 45 | Roi Et |
| TH | 27 | Sa Kaeo |
| TH | 47 | Sakon Nakhon |
| TH | 11 | Samut Prakan |
| TH | 74 | Samut Sakhon |
| TH | 75 | Samut Songkhram |
| TH | 19 | Sara Buri |
| TH | 91 | Satun |
| TH | 17 | Sing Buri |
| TH | 33 | Sisaket |
| TH | 90 | Songkhla |
| TH | 64 | Sukhothai |
| TH | 72 | Suphan Buri |
| TH | 84 | Surat Thani |
| TH | 32 | Surin |
| TH | 63 | Tak |
| TH | 92 | Trang |
| TH | 23 | Trat |
| TH | 34 | Ubon Ratchathani |
| TH | 41 | Udon Thani |
| TH | 61 | Uthai Thani |
| TH | 53 | Uttaradit |
| TH | 95 | Yala |
| TH | 35 | Yasothon |
| TH | 38 | Bueng Kan |
| TH | S | Phatthaya |
| TL | AL | Aileu |
| TL | AN | Ainaro |
| TL | BA | Baucau |
| TL | BO | Bobonaro |
| TL | CO | Cova Lima |
| TL | DI | Dili |
| TL | ER | Ermera |
| TL | LA | Lautem |
| TL | LI | Liquica |
| TL | MT | Manatuto |
| TL | MF | Manufahi |
| TL | OE | Oecussi |
| TL | VI | Viqueque |
| TG | C | Centrale |
| TG | K | Kara |
| TG | M | Maritime |
| TG | P | Plateaux |
| TG | S | Savanes |
| TO | 02 | Ha’apai |
| TO | 04 | Tongatapu |
| TO | 05 | Vava’u |
| TO | 01 | ‘Eua |
| TO | 03 | Niuas |
| TT | ARI | Arima |
| TT | CHA | Chaguanas |
| TT | DMN | Diego Martin |
| TT | PTF | Point Fortin |
| TT | POS | Port of Spain |
| TT | PRT | Princes Town |
| TT | SFO | San Fernando |
| TT | SGE | Sangre Grande |
| TT | SIP | Siparia |
| TT | TOB | Tobago |
| TT | CTT | Couva-Tabaquite-Talparo |
| TT | MRC | Mayaro-Rio Claro |
| TT | PED | Penal-Debe |
| TT | SJL | San Juan-Laventille |
| TT | TUP | Tunapuna-Piarco |
| TN | 31 | Beja |
| TN | 13 | Ben Arous |
| TN | 23 | Bizerte |
| TN | 81 | Gabes |
| TN | 71 | Gafsa |
| TN | 32 | Jendouba |
| TN | 41 | Kairouan |
| TN | 42 | Kasserine |
| TN | 73 | Kebili |
| TN | 53 | Mahdia |
| TN | 82 | Medenine |
| TN | 52 | Monastir |
| TN | 21 | Nabeul |
| TN | 61 | Sfax |
| TN | 34 | Siliana |
| TN | 51 | Sousse |
| TN | 83 | Tataouine |
| TN | 72 | Tozeur |
| TN | 11 | Tunis |
| TN | 22 | Zaghouan |
| TN | 12 | L’Ariana |
| TN | 14 | La Manouba |
| TN | 33 | Le Kef |
| TN | 43 | Sidi Bouzid |
| TR | 01 | Adana |
| TR | 02 | Adiyaman |
| TR | 03 | Afyonkarahisar |
| TR | 04 | Agri |
| TR | 68 | Aksaray |
| TR | 05 | Amasya |
| TR | 06 | Ankara |
| TR | 07 | Antalya |
| TR | 75 | Ardahan |
| TR | 08 | Artvin |
| TR | 09 | Aydin |
| TR | 10 | Balikesir |
| TR | 74 | Bartin |
| TR | 72 | Batman |
| TR | 69 | Bayburt |
| TR | 11 | Bilecik |
| TR | 12 | Bingol |
| TR | 13 | Bitlis |
| TR | 14 | Bolu |
| TR | 15 | Burdur |
| TR | 16 | Bursa |
| TR | 17 | Canakkale |
| TR | 18 | Cankiri |
| TR | 19 | Corum |
| TR | 20 | Denizli |
| TR | 21 | Diyarbakir |
| TR | 81 | Duzce |
| TR | 22 | Edirne |
| TR | 23 | Elazig |
| TR | 24 | Erzincan |
| TR | 25 | Erzurum |
| TR | 26 | Eskisehir |
| TR | 27 | Gaziantep |
| TR | 28 | Giresun |
| TR | 29 | Gumushane |
| TR | 30 | Hakkari |
| TR | 31 | Hatay |
| TR | 76 | Igdir |
| TR | 32 | Isparta |
| TR | 34 | Istanbul |
| TR | 35 | Izmir |
| TR | 46 | Kahramanmaras |
| TR | 78 | Karabuk |
| TR | 70 | Karaman |
| TR | 36 | Kars |
| TR | 37 | Kastamonu |
| TR | 38 | Kayseri |
| TR | 79 | Kilis |
| TR | 71 | Kirikkale |
| TR | 39 | Kirklareli |
| TR | 40 | Kirsehir |
| TR | 41 | Kocaeli |
| TR | 42 | Konya |
| TR | 43 | Kutahya |
| TR | 44 | Malatya |
| TR | 45 | Manisa |
| TR | 47 | Mardin |
| TR | 33 | Mersin |
| TR | 48 | Mugla |
| TR | 49 | Mus |
| TR | 50 | Nevsehir |
| TR | 51 | Nigde |
| TR | 52 | Ordu |
| TR | 80 | Osmaniye |
| TR | 53 | Rize |
| TR | 54 | Sakarya |
| TR | 55 | Samsun |
| TR | 63 | Sanliurfa |
| TR | 56 | Siirt |
| TR | 57 | Sinop |
| TR | 73 | Sirnak |
| TR | 58 | Sivas |
| TR | 59 | Tekirdag |
| TR | 60 | Tokat |
| TR | 61 | Trabzon |
| TR | 62 | Tunceli |
| TR | 64 | Usak |
| TR | 65 | Van |
| TR | 77 | Yalova |
| TR | 66 | Yozgat |
| TR | 67 | Zonguldak |
| TM | A | Ahal Welayaty |
| TM | B | Balkan Welayaty |
| TM | D | Dashhowuz Welayaty |
| TM | L | Lebap Welayaty |
| TM | M | Mary Welayaty |
| TM | S | Aşgabat |
| TV | FUN | Funafuti |
| TV | NMG | Nanumanga |
| TV | NMA | Nanumea |
| TV | NIT | Niutao |
| TV | NUI | Nui |
| TV | NKF | Nukufetau |
| TV | NKL | Nukulaelae |
| TV | VAI | Vaitupu |
| UG | 301 | Adjumani |
| UG | 302 | Apac |
| UG | 303 | Arua |
| UG | 201 | Bugiri |
| UG | 401 | Bundibugyo |
| UG | 402 | Bushenyi |
| UG | 202 | Busia |
| UG | 304 | Gulu |
| UG | 403 | Hoima |
| UG | 203 | Iganga |
| UG | 204 | Jinja |
| UG | 404 | Kabale |
| UG | 405 | Kabarole |
| UG | 213 | Kaberamaido |
| UG | 101 | Kalangala |
| UG | 102 | Kampala |
| UG | 205 | Kamuli |
| UG | 413 | Kamwenge |
| UG | 414 | Kanungu |
| UG | 206 | Kapchorwa |
| UG | 406 | Kasese |
| UG | 207 | Katakwi |
| UG | 112 | Kayunga |
| UG | 407 | Kibaale |
| UG | 103 | Kiboga |
| UG | 408 | Kisoro |
| UG | 305 | Kitgum |
| UG | 306 | Kotido |
| UG | 208 | Kumi |
| UG | 415 | Kyenjojo |
| UG | 307 | Lira |
| UG | 104 | Luwero |
| UG | 105 | Masaka |
| UG | 409 | Masindi |
| UG | 214 | Mayuge |
| UG | 209 | Mbale |
| UG | 410 | Mbarara |
| UG | 308 | Moroto |
| UG | 309 | Moyo |
| UG | 106 | Mpigi |
| UG | 107 | Mubende |
| UG | 108 | Mukono |
| UG | 311 | Nakapiripirit |
| UG | 109 | Nakasongola |
| UG | 310 | Nebbi |
| UG | 411 | Ntungamo |
| UG | 312 | Pader |
| UG | 210 | Pallisa |
| UG | 110 | Rakai |
| UG | 412 | Rukungiri |
| UG | 111 | Sembabule |
| UG | 215 | Sironko |
| UG | 211 | Soroti |
| UG | 212 | Tororo |
| UG | 113 | Wakiso |
| UG | 313 | Yumbe |
| UG | 114 | Lyantonde |
| UG | 115 | Mityana |
| UG | 116 | Nakaseke |
| UG | 117 | Buikwe |
| UG | 118 | Bukomansibi |
| UG | 119 | Butambala |
| UG | 120 | Buvuma |
| UG | 121 | Gomba |
| UG | 122 | Kalungu |
| UG | 123 | Kyankwanzi |
| UG | 124 | Lwengo |
| UG | 125 | Kyotera |
| UG | 126 | Kasanda |
| UG | 216 | Amuria |
| UG | 217 | Budaka |
| UG | 218 | Bududa |
| UG | 219 | Bukedea |
| UG | 220 | Bukwo |
| UG | 221 | Butaleja |
| UG | 222 | Kaliro |
| UG | 223 | Manafwa |
| UG | 224 | Namutumba |
| UG | 225 | Bulambuli |
| UG | 226 | Buyende |
| UG | 227 | Kibuku |
| UG | 228 | Kween |
| UG | 229 | Luuka |
| UG | 230 | Namayingo |
| UG | 231 | Ngora |
| UG | 232 | Serere |
| UG | 233 | Butebo |
| UG | 234 | Namisindwa |
| UG | 235 | Bugweri |
| UG | 236 | Kapelebyong |
| UG | 237 | Kalaki |
| UG | 314 | Abim |
| UG | 315 | Amolatar |
| UG | 316 | Amuru |
| UG | 317 | Dokolo |
| UG | 318 | Kaabong |
| UG | 319 | Koboko |
| UG | 320 | Maracha |
| UG | 321 | Oyam |
| UG | 322 | Agago |
| UG | 323 | Alebtong |
| UG | 324 | Amudat |
| UG | 325 | Kole |
| UG | 326 | Lamwo |
| UG | 327 | Napak |
| UG | 328 | Nwoya |
| UG | 329 | Otuke |
| UG | 330 | Zombo |
| UG | 331 | Omoro |
| UG | 332 | Pakwach |
| UG | 333 | Kwania |
| UG | 334 | Nabilatuk |
| UG | 335 | Karenga |
| UG | 336 | Madi-Okollo |
| UG | 337 | Obongi |
| UG | 416 | Buliisa |
| UG | 417 | Ibanda |
| UG | 418 | Isingiro |
| UG | 419 | Kiruhura |
| UG | 420 | Buhweju |
| UG | 421 | Kiryandongo |
| UG | 422 | Kyegegwa |
| UG | 423 | Mitooma |
| UG | 424 | Ntoroko |
| UG | 425 | Rubirizi |
| UG | 426 | Sheema |
| UG | 427 | Kagadi |
| UG | 428 | Kakumiro |
| UG | 429 | Rubanda |
| UG | 430 | Bunyangabu |
| UG | 431 | Rukiga |
| UG | 432 | Kikuube |
| UG | 433 | Kazo |
| UG | 434 | Kitagwenda |
| UG | 435 | Rwampara |
| UG | C | Central |
| UG | E | Eastern |
| UG | N | Northern |
| UG | W | Western |
| UA | 40 | Sevastopol |
| UA | 05 | Vinnytska oblast |
| UA | 07 | Volynska oblast |
| UA | 09 | Luhanska oblast |
| UA | 12 | Dnipropetrovska oblast |
| UA | 14 | Donetska oblast |
| UA | 18 | Zhytomyrska oblast |
| UA | 21 | Zakarpatska oblast |
| UA | 23 | Zaporizka oblast |
| UA | 26 | Ivano-Frankivska oblast |
| UA | 30 | Kyiv |
| UA | 32 | Kyivska oblast |
| UA | 35 | Kirovohradska oblast |
| UA | 43 | Avtonomna Respublika Krym |
| UA | 46 | Lvivska oblast |
| UA | 48 | Mykolaivska oblast |
| UA | 51 | Odeska oblast |
| UA | 53 | Poltavska oblast |
| UA | 56 | Rivnenska oblast |
| UA | 59 | Sumska oblast |
| UA | 61 | Ternopilska oblast |
| UA | 63 | Kharkivska oblast |
| UA | 65 | Khersonska oblast |
| UA | 68 | Khmelnytska oblast |
| UA | 71 | Cherkaska oblast |
| UA | 74 | Chernihivska oblast |
| UA | 77 | Chernivetska oblast |
| AE | AJ | ‘Ajman |
| AE | AZ | Abu Zaby |
| AE | FU | Al Fujayrah |
| AE | SH | Ash Shariqah |
| AE | DU | Dubayy |
| AE | RK | R’as al Khaymah |
| AE | UQ | Umm al Qaywayn |
| GB | ABE | Aberdeen City |
| GB | ABD | Aberdeenshire |
| GB | ANS | Angus |
| GB | AGB | Argyll and Bute |
| GB | BDG | Barking and Dagenham |
| GB | BNE | Barnet |
| GB | BNS | Barnsley |
| GB | BAS | Bath and North East Somerset |
| GB | BDF | Bedfordshire |
| GB | BFS | Belfast |
| GB | BEX | Bexley |
| GB | BIR | Birmingham |
| GB | BBD | Blackburn with Darwen |
| GB | BPL | Blackpool |
| GB | BGW | Blaenau Gwent |
| GB | BOL | Bolton |
| GB | BRC | Bracknell Forest |
| GB | BRD | Bradford |
| GB | BEN | Brent |
| GB | BGE | Bridgend [Pen-y-bont ar Ogwr GB-POG] |
| GB | BNH | Brighton and Hove |
| GB | BST | “Bristol, City of” |
| GB | BRY | Bromley |
| GB | BKM | Buckinghamshire |
| GB | BUR | Bury |
| GB | CAY | Caerphilly [Caerffili GB-CAF] |
| GB | CLD | Calderdale |
| GB | CAM | Cambridgeshire |
| GB | CMD | Camden |
| GB | CRF | Cardiff [Caerdydd GB-CRD] |
| GB | CMN | Carmarthenshire [Sir Gaerfyrddin GB-GFY] |
| GB | CBF | Central Bedfordshire |
| GB | CGN | Ceredigion [Sir Ceredigion] |
| GB | CHE | Cheshire East |
| GB | CHW | Cheshire West and Chester |
| GB | CLK | Clackmannanshire |
| GB | CWY | Conwy |
| GB | CON | Cornwall |
| GB | COV | Coventry |
| GB | CRY | Croydon |
| GB | CMA | Cumbria |
| GB | DAL | Darlington |
| GB | DEN | Denbighshire [Sir Ddinbych GB-DDB] |
| GB | DBY | Derbyshire |
| GB | DER | Derby |
| GB | DEV | Devon |
| GB | DNC | Doncaster |
| GB | DOR | Dorset |
| GB | DUD | Dudley |
| GB | DGY | Dumfries and Galloway |
| GB | DND | Dundee City |
| GB | DUR | Durham |
| GB | EAL | Ealing |
| GB | EAY | East Ayrshire |
| GB | EDU | East Dunbartonshire |
| GB | ELN | East Lothian |
| GB | ERW | East Renfrewshire |
| GB | ERY | East Riding of Yorkshire |
| GB | ESX | East Sussex |
| GB | EDH | “Edinburgh, City of” |
| GB | ELS | Eilean Siar |
| GB | ENF | Enfield |
| GB | ESS | Essex |
| GB | FAL | Falkirk |
| GB | FIF | Fife |
| GB | FLN | Flintshire [Sir y Fflint GB-FFL] |
| GB | GAT | Gateshead |
| GB | GLG | Glasgow City |
| GB | GLS | Gloucestershire |
| GB | GRE | Greenwich |
| GB | GWN | Gwynedd |
| GB | HCK | Hackney |
| GB | HAL | Halton |
| GB | HMF | Hammersmith and Fulham |
| GB | HAM | Hampshire |
| GB | HRY | Haringey |
| GB | HRW | Harrow |
| GB | HPL | Hartlepool |
| GB | HAV | Havering |
| GB | HEF | “Herefordshire, County of” |
| GB | HRT | Hertfordshire |
| GB | HLD | Highland |
| GB | HIL | Hillingdon |
| GB | HNS | Hounslow |
| GB | IVC | Inverclyde |
| GB | AGY | Isle of Anglesey [Sir Ynys Môn GB-YNM] |
| GB | IOW | Isle of Wight |
| GB | ISL | Islington |
| GB | KEC | Kensington and Chelsea |
| GB | KEN | Kent |
| GB | KHL | “Kingston upon Hull, City of” |
| GB | KTT | Kingston upon Thames |
| GB | KIR | Kirklees |
| GB | KWL | Knowsley |
| GB | LBH | Lambeth |
| GB | LAN | Lancashire |
| GB | LDS | Leeds |
| GB | LEC | Leicestershire |
| GB | LCE | Leicester |
| GB | LEW | Lewisham |
| GB | LIN | Lincolnshire |
| GB | LIV | Liverpool |
| GB | LND | “London, City of” |
| GB | LUT | Luton |
| GB | MAN | Manchester |
| GB | MDW | Medway |
| GB | MTY | Merthyr Tydfil [Merthyr Tudful GB-MTU] |
| GB | MRT | Merton |
| GB | MDB | Middlesbrough |
| GB | MLN | Midlothian |
| GB | MIK | Milton Keynes |
| GB | MON | Monmouthshire [Sir Fynwy GB-FYN] |
| GB | MRY | Moray |
| GB | NTL | Neath Port Talbot [Castell-nedd Port Talbot GB-CTL] |
| GB | NET | Newcastle upon Tyne |
| GB | NWM | Newham |
| GB | NWP | Newport [Casnewydd GB-CNW] |
| GB | NFK | Norfolk |
| GB | NAY | North Ayrshire |
| GB | NEL | North East Lincolnshire |
| GB | NLK | North Lanarkshire |
| GB | NLN | North Lincolnshire |
| GB | NSM | North Somerset |
| GB | NTY | North Tyneside |
| GB | NYK | North Yorkshire |
| GB | NTH | Northamptonshire |
| GB | NBL | Northumberland |
| GB | NTT | Nottinghamshire |
| GB | NGM | Nottingham |
| GB | OLD | Oldham |
| GB | ORK | Orkney Islands |
| GB | OXF | Oxfordshire |
| GB | PEM | Pembrokeshire [Sir Benfro GB-BNF] |
| GB | PKN | Perth and Kinross |
| GB | PTE | Peterborough |
| GB | PLY | Plymouth |
| GB | POR | Portsmouth |
| GB | POW | Powys |
| GB | RDG | Reading |
| GB | RDB | Redbridge |
| GB | RCC | Redcar and Cleveland |
| GB | RFW | Renfrewshire |
| GB | RCT | “Rhondda, Cynon, Taff [Rhondda, Cynon,Taf]” |
| GB | RIC | Richmond upon Thames |
| GB | RCH | Rochdale |
| GB | ROT | Rotherham |
| GB | RUT | Rutland |
| GB | SLF | Salford |
| GB | SAW | Sandwell |
| GB | SCB | “Scottish Borders, The” |
| GB | SFT | Sefton |
| GB | SHF | Sheffield |
| GB | ZET | Shetland Islands |
| GB | SHR | Shropshire |
| GB | SLG | Slough |
| GB | SOL | Solihull |
| GB | SOM | Somerset |
| GB | SAY | South Ayrshire |
| GB | SGC | South Gloucestershire |
| GB | SLK | South Lanarkshire |
| GB | STY | South Tyneside |
| GB | STH | Southampton |
| GB | SOS | Southend-on-Sea |
| GB | SWK | Southwark |
| GB | SHN | St. Helens |
| GB | STS | Staffordshire |
| GB | STG | Stirling |
| GB | SKP | Stockport |
| GB | STT | Stockton-on-Tees |
| GB | STE | Stoke-on-Trent |
| GB | SFK | Suffolk |
| GB | SND | Sunderland |
| GB | SRY | Surrey |
| GB | STN | Sutton |
| GB | SWA | Swansea [Abertawe GB-ATA] |
| GB | SWD | Swindon |
| GB | TAM | Tameside |
| GB | TFW | Telford and Wrekin |
| GB | THR | Thurrock |
| GB | TOB | Torbay |
| GB | TOF | Torfaen [Tor-faen] |
| GB | TWH | Tower Hamlets |
| GB | TRF | Trafford |
| GB | VGL | “Vale of Glamorgan, The [Bro Morgannwg GB-BMG]” |
| GB | WKF | Wakefield |
| GB | WLL | Walsall |
| GB | WFT | Waltham Forest |
| GB | WND | Wandsworth |
| GB | WRT | Warrington |
| GB | WAR | Warwickshire |
| GB | WBK | West Berkshire |
| GB | WDU | West Dunbartonshire |
| GB | WLN | West Lothian |
| GB | WSX | West Sussex |
| GB | WSM | Westminster |
| GB | WGN | Wigan |
| GB | WIL | Wiltshire |
| GB | WNM | Windsor and Maidenhead |
| GB | WRL | Wirral |
| GB | WOK | Wokingham |
| GB | WLV | Wolverhampton |
| GB | WOR | Worcestershire |
| GB | WRX | Wrexham [Wrecsam GB-WRC] |
| GB | YOR | York |
| GB | ABC | “Armagh City, Banbridge and Craigavon” |
| GB | AND | Ards and North Down |
| GB | ANN | Antrim and Newtownabbey |
| GB | BCP | “Bournemouth, Christchurch and Poole” |
| GB | CCG | Causeway Coast and Glens |
| GB | DRS | Derry and Strabane |
| GB | FMO | Fermanagh and Omagh |
| GB | IOS | Isles of Scilly |
| GB | LBC | Lisburn and Castlereagh |
| GB | MEA | Mid and East Antrim |
| GB | MUL | Mid-Ulster |
| GB | NMD | “Newry, Mourne and Down” |
| UM | 81 | Baker Island |
| UM | 84 | Howland Island |
| UM | 86 | Jarvis Island |
| UM | 67 | Johnston Atoll |
| UM | 89 | Kingman Reef |
| UM | 76 | Navassa Island |
| UM | 95 | Palmyra Atoll |
| UM | 79 | Wake Island |
| UM | 71 | Midway Islands |
| UY | AR | Artigas |
| UY | CA | Canelones |
| UY | CL | Cerro Largo |
| UY | CO | Colonia |
| UY | DU | Durazno |
| UY | FS | Flores |
| UY | FD | Florida |
| UY | LA | Lavalleja |
| UY | MA | Maldonado |
| UY | MO | Montevideo |
| UY | PA | Paysandu |
| UY | RN | Rio Negro |
| UY | RV | Rivera |
| UY | RO | Rocha |
| UY | SA | Salto |
| UY | SJ | San Jose |
| UY | SO | Soriano |
| UY | TA | Tacuarembo |
| UY | TT | Treinta y Tres |
| UZ | AN | Andijon |
| UZ | BU | Buxoro |
| UZ | FA | Farg’ona |
| UZ | JI | Jizzax |
| UZ | NG | Namangan |
| UZ | NW | Navoiy |
| UZ | QA | Qashqadaryo |
| UZ | QR | Qoraqalpog’iston Republikasi |
| UZ | SA | Samarqand |
| UZ | SI | Sirdaryo |
| UZ | SU | Surxondaryo |
| UZ | TK | Toshkent City |
| UZ | TO | Toshkent Region |
| UZ | XO | Xorazm |
| VU | MAP | Malampa |
| VU | PAM | Penama |
| VU | SAM | Sanma |
| VU | SEE | Shefa |
| VU | TAE | Tafea |
| VU | TOB | Torba |
| VE | Z | Amazonas |
| VE | B | Anzoategui |
| VE | C | Apure |
| VE | D | Aragua |
| VE | E | Barinas |
| VE | F | Bolivar |
| VE | G | Carabobo |
| VE | H | Cojedes |
| VE | Y | Delta Amacuro |
| VE | W | Dependencias Federales |
| VE | I | Falcon |
| VE | J | Guarico |
| VE | K | Lara |
| VE | L | Merida |
| VE | M | Miranda |
| VE | N | Monagas |
| VE | O | Nueva Esparta |
| VE | P | Portuguesa |
| VE | R | Sucre |
| VE | S | Tachira |
| VE | T | Trujillo |
| VE | U | Yaracuy |
| VE | V | Zulia |
| VE | A | Distrito Capital |
| VE | X | La Guaira |
| VN | 44 | An Giang |
| VN | 54 | Bac Giang |
| VN | 53 | Bac Kan |
| VN | 55 | Bac Lieu |
| VN | 56 | Bac Ninh |
| VN | 50 | Ben Tre |
| VN | 57 | Binh Duong |
| VN | 58 | Binh Phuoc |
| VN | 40 | Binh Thuan |
| VN | 59 | Ca Mau |
| VN | CT | Can Tho |
| VN | 04 | Cao Bang |
| VN | DN | Da Nang |
| VN | 30 | Gia Lai |
| VN | 03 | Ha Giang |
| VN | 63 | Ha Nam |
| VN | HN | Ha Noi |
| VN | 23 | Ha Tinh |
| VN | 61 | Hai Duong |
| VN | HP | Hai Phong |
| VN | 73 | Hau Giang |
| VN | 14 | Hoa Binh |
| VN | 66 | Hung Yen |
| VN | 01 | Lai Châu |
| VN | 02 | Lào Cai |
| VN | 05 | Sơn La |
| VN | 06 | Yên Bái |
| VN | 07 | Tuyên Quang |
| VN | 09 | Lạng Sơn |
| VN | 13 | Quảng Ninh |
| VN | 18 | Ninh Bình |
| VN | 20 | Thái Bình |
| VN | 21 | Thanh Hóa |
| VN | 22 | Nghệ An |
| VN | 24 | Quảng Bình |
| VN | 25 | Quảng Trị |
| VN | 26 | Thừa Thiên-Huế |
| VN | 27 | Quảng Nam |
| VN | 28 | Kon Tum |
| VN | 29 | Quảng Ngãi |
| VN | 31 | Bình Định |
| VN | 32 | Phú Yên |
| VN | 33 | Đắk Lắk |
| VN | 34 | Khánh Hòa |
| VN | 35 | Lâm Đồng |
| VN | 36 | Ninh Thuận |
| VN | 37 | Tây Ninh |
| VN | 39 | Đồng Nai |
| VN | 41 | Long An |
| VN | 43 | Bà Rịa - Vũng Tàu |
| VN | 45 | Đồng Tháp |
| VN | 46 | Tiền Giang |
| VN | 47 | Kiến Giang |
| VN | 49 | Vĩnh Long |
| VN | 51 | Trà Vinh |
| VN | 52 | Sóc Trăng |
| VN | 67 | Nam Định |
| VN | 68 | Phú Thọ |
| VN | 69 | Thái Nguyên |
| VN | 70 | Vĩnh Phúc |
| VN | 71 | Điện Biên |
| VN | 72 | Đắk Nông |
| VN | SG | Hồ Chí Minh |
| WF | AL | Alo |
| WF | SG | Sigave |
| WF | UV | Uvea |
| YE | AB | Abyan |
| YE | DA | Ad Dali |
| YE | AD | Adan |
| YE | BA | Al Bayda |
| YE | HU | Al Hudaydah |
| YE | JA | Al Jawf |
| YE | MR | Al Mahrah |
| YE | MW | Al Mahwit |
| YE | AM | Amran |
| YE | DH | Dhamar |
| YE | HD | Hadramawt |
| YE | HJ | Hajjah |
| YE | IB | Ibb |
| YE | LA | Lahij |
| YE | MA | Ma’rib |
| YE | SD | Sa’dah |
| YE | SN | San’a |
| YE | SH | Shabwah |
| YE | TA | Ta’izz |
| YE | RA | Raymah |
| YE | SA | Amānat al ‘Āşimah [city] |
| YE | SU | Arkhabīl Suquţrá |
| ZM | 02 | Central |
| ZM | 08 | Copperbelt |
| ZM | 03 | Eastern |
| ZM | 04 | Luapula |
| ZM | 09 | Lusaka |
| ZM | 06 | North-Western |
| ZM | 05 | Northern |
| ZM | 07 | Southern |
| ZM | 01 | Western |
| ZM | 10 | Muchinga |
| ZW | BU | Bulawayo |
| ZW | HA | Harare |
| ZW | MA | Manicaland |
| ZW | MC | Mashonaland Central |
| ZW | ME | Mashonaland East |
| ZW | MW | Mashonaland West |
| ZW | MV | Masvingo |
| ZW | MN | Matabeleland North |
| ZW | MS | Matabeleland South |
| ZW | MI | Midlands |
| BQ | BO | Boneiru |
| BQ | SA | Saba |
| BQ | SE | Sint Eustatius |
| SS | BN | Northern Bahr el Ghazal |
| SS | BW | Western Bahr el Ghazal |
| SS | EC | Central Equatoria |
| SS | EE | Eastern Equatoria |
| SS | EW | Western Equatoria |
| SS | JG | Jonglei |
| SS | LK | Lakes |
| SS | NU | Upper Nile |
| SS | UY | Unity |
| SS | WR | Warrap |

### CS-Cart

The CS-Cart plugin integrates Payneteasy payment processing with the [CS-Cart](https://www.cs-cart.com/) e-commerce platform. It ships as a standard CS-Cart addon (module id `payneteasy`, display name “Paynet Easy Payment”) that registers a new payment processor in the store’s admin panel, so shop administrators can accept card payments through Payneteasy without writing custom code.

A live example of the checkout flow produced by this plugin can be seen on the [CS-Cart demo shop](https://cscart.codetime.net/).

#### Source code

The plugin source is published on Git Hub at [payneteasy/php-plugin-cscart](https://github.com/payneteasy/php-plugin-cscart). The repository contains the addon files under `app/addons/payneteasy` (install/uninstall logic, the payment processor registration, and language files) together with the corresponding `design` templates for the CS-Cart storefront and admin area.

### Currency Codes

| Currency code | Description |
|-----------------|-----------------------------------------|
| AED | United Arab Emirates dirham |
| ALL | Albanian lek |
| AMD | Armenian dram |
| ARS | Argentine peso |
| AUD | Australian dollar |
| AZN | Azerbaijani manat |
| BAM | Bosnia and Herzegovina convertible mark |
| BDT | Bangladeshi taka |
| BGN | Bulgarian lev (obsolete) |
| BHD | Bahraini dinar |
| BIF | Burundian franc |
| BOB | Bolivian boliviano |
| BRL | Brazilian real |
| BWP | Botswana pula |
| BYN | Belarusian ruble |
| CAD | Canadian dollar |
| CDF | Congolese franc |
| CHF | Swiss franc |
| CLP | Chilean peso |
| CNY | Chinese yuan |
| COP | Colombian peso |
| CRC | Costa Rican colón |
| CVE | Cape Verdean escudo |
| CZK | Czech koruna |
| DKK | Danish krone |
| DJF | Djiboutian franc |
| DLS | DLS Loyalty program |
| DOP | Dominican peso |
| DZD | Algerian dinar |
| EGP | Egyptian pound |
| ERN | Eritrean nakfa |
| ETB | Ethiopian birr |
| EUR | Euro |
| FIM | Finnish markka (obsolete) |
| GBP | Pound sterling |
| GEL | Georgian lari |
| GHS | Ghanaian cedi |
| GMD | Gambian dalasi |
| GNF | Guinean franc |
| GTQ | Guatemalan quetzal |
| HKD | Hong Kong dollar |
| HNL | Honduran lempira |
| HRK | Croatian kuna (obsolete) |
| HUF | Hungarian forint |
| IDR | Indonesian rupiah |
| ILS | Israeli new shekel |
| INR | Indian rupee |
| IRR | Iranian rial |
| ISK | Icelandic króna |
| JOD | Jordanian dinar |
| JPY | Japanese yen |
| KES | Kenyan shilling |
| KGS | Kyrgyzstani som |
| KHR | Cambodian riel |
| KMF | Comoro franc |
| Won | Korean Republic Won |
| KWD | Kuwaiti dinar |
| KZT | Kazakhstani tenge |
| LAK | Lao kip |
| LKR | Sri Lankan rupee |
| LSL | Lesotho loti |
| MAD | Moroccan dirham |
| MDL | Moldovan leu |
| MGA | Malagasy ariary |
| MKD | Macedonian denar |
| MMK | Myanmar kyat |
| MNT | Mongolian tögrög |
| MRU | Mauritanian ouguiya |
| MUR | Mauritian rupee |
| MWK | Malawian kwacha |
| MXN | Mexican peso |
| MYR | Malaysian ringgit |
| MZN | Mozambican metical |
| NAD | Namibian dollar |
| NGN | Nigerian naira |
| NIO | Nicaraguan córdoba |
| NOK | Norwegian krone |
| NZD | New Zealand dollar |
| OMR | Omani rial |
| PAB | Panamanian balboa |
| PEN | Peruvian sol |
| PHP | Philippine peso |
| PKR | Pakistani rupee |
| PLN | Polish złoty |
| PYG | Paraguayan guaraní |
| QAR | Qatari riyal |
| RON | Romanian leu |
| RSD | Serbian dinar |
| RUB | Russian ruble |
| RWF | Rwandan franc |
| SAR | Saudi riyal |
| SCR | Seychelles rupee |
| SEK | Swedish krona |
| SGD | Singapore dollar |
| SHP | Saint Helena pound |
| SLE | Sierra Leonean leone |
| SRD | Surinamese dollar |
| STN | São Tomé and Príncipe dobra |
| SZL | Eswatini lilangeni |
| THB | Thai baht |
| TJS | Tajikistani somoni |
| TMT | Turkmenistani manat |
| TND | Tunisian dinar |
| TRY | Turkish lira |
| TWD | Taiwan dollar |
| TZS | Tanzanian shilling |
| UAH | Ukrainian hryvnia |
| UGX | Ugandan Shilling |
| USD | United States Dollar |
| UYU | Uruguayan peso |
| UZS | Uzbekistani som |
| VES | Venezuelan bolívar soberano |
| VND | Vietnamese dong |
| WMZ | Web Money WMZ (USD) |
| XAF | Central African CFA franc |
| XOF | West African CFA franc |
| ZAR | South African rand |
| ZMW | Zambian kwacha |
| BTC | Bitcoin |
| μBTC | Micro Bitcoin |
| USDT | Tether (stablecoin) |
| UNS | Unspecified currency (XXX) |

### Data migration

Sensitive information, such as cardholder data, must be encrypted for PCI-compliant migration. Encryption is made with Payneteasy PGP key.

After [importing](https://www.gnupg.org/gph/en/manual.html#AEN84) Payneteasy PGP key, run the following command to encrypt the files before sending. file_name.gpg will be created:

```text
gpg --encrypt --recipient 3C7266AE file_name
```

Payneteasy Public PGP Key

Key ID: 91D14F90
 
Key type: RSA
 
Key size: 4096 bits
 
Fingerprint: C519 7432 AF07 595A C081 3B83 3501 1DD3 CBC2 E0AB
 
User ID: Payneteasy Import Key (PCI) <[security@Payneteasy.ru](mailto:security@Payneteasy.ru)>
 
```http
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.22 (GNU/Linux)

mQINBGLNircBEADNI7fzBBc2NyhhzKGb1gI94ASwNqA37dxPaC8bW1hxThaZV0Aj
jPc1EbMT9UdSjJgHZafvAqYo0EUfJqCS1BFnhjTrHiWWBr1dKQ35dMkUB4UWmius
vungosQeFgAy70eY4MS+2r05DYaBylHHhc/0TZ+v0UOaQp8ch2Uu2C6N7wYT97nV
DC0373StsON36m6k1pXLYuTSzXX9ZgZlLYvK1gyItvBqziT7AsSHeGFFjCFygcCL
i3qrmT2S4JBDXQTDaSCWG36aGTerMvkGlwixnpj6nw1E6GJsApQNY7qahn2rY3UK
40Fk7BniHLbFmR4AK5RvDWNTgu3jDdc1z9dS/6n3beM9HExly3TjpmlZDa1CxhtH
W3o69m/3BbzLOjgW6XQX1QoCjuv1ejw6Hm1b5dphyab2xXfEXS40jghuTKTMK7TN
gAsOn8siD4zTedcWdo4rUUX/WATtyRAyFBDLzORFxj4iRezGda1XfTOIgRqPc/3U
ggQhOT6BQuevdtuHjdSNY36TEJHOPi28xMOPMMpMVA5nPBHX/L+I6Z8Z9/pGDZPa
mQwlg5XebtL2t3AakGQ8goobImavQrNgDPQU+hf3maNAkBzKirqLVcAKjqG/KX7v
AMNUzzXCRqc/yGEobJuSa0wTpf2pJhHqExrAgbn3FEBiu42kY/wE20jyLQARAQAB
tDRQYXluZXRlYXN5IEltcG9ydCBLZXkgKFBDSSkgPHNlY3VyaXR5QHBheW5ldGVh
c3kucnU+iQI/BBMBAgApBQJizYq3AhsDBQkDwmcABwsJCAcDAgEGFQgCCQoLBBYC
AwECHgECF4AACgkQNQEd08vC4KubdA/9G0okz/MOp6Nz7DE2u7Hz0OVoP5OMHQ+U
TdXINlYG0PWJGricF5ohw5jYp/iwgumAb9lXJBc0/h3LZBemW/H0/HCID+wFJT6p
kSoQ2ZGKL37MRdJ6kf9H+VMjGJYS0VOJoj1xWiwUhBjmjeWCAGx88Ovej9IzZsaO
F9hCgsB/PiTm95wdqpwEfh0Cy+C5r03PoWOsa8v4bpMwl3PaNxifaD+uorJX4kOF
EvGIOkrm3o1C6gkZJR2f6RLnazDFlW0KmXUOik1MEosKYCprY2Bk3wBZ0GskyLlY
jcKppVdzfeX66vYUlczR57mlk3GSZzCQHl5fBFoX+yUY+IiowRVqjmneFP6rv9MY
Csvcl/2vdJ8Ou4pyRmRcxJiYhoNSxowWTenbhj40KHUfw7YH3/VLY2UI/LBedEMF
Dx0CqtHSNVogeb5RzzIbhySeXAut79In8AAsvtNT/OMF5ZrZtlNBi6wqZO/invgv
UkdCngSL0+TZAOySwfR0iNZaZJmZ/DfrBuP9p82HZRyK7X9GB/5Ziqs8WStOIzJr
2iQVB9TCKIrE7kWHFxA7HNzfWYgWU32lx/2R+0cH4zwuhFH2rKfrBR6Ekgl8F0+m
tuYqMMBCagF0U6OhFqTtTiQ3cz1A8inNlVkVv9AHI/2Rl5w9hRb88139TtV7aeK2
jbYLHaIwmZC5Ag0EYs2KtwEQAMwaMSjHenq5rU/vVNhhisKKvrzrzHtRFiSnshs8
cWWtr2hyAVRb+loZa5trBs6pal/X+V/fAm7LWBSjt0z1gyZfgamf0PHvmWl5JHiK
O6x22qYLS/F4O4d/tDwUPdPJPx/FXYu/q50B4IsJ0zfoKW2Zwp9hCUoY67EM+8c+
NF5pTqbZ8Fp7zM1oHIkhYRga2qXRW5lxhC8Xojc/nZp65qwW+r2JVlBECa/A2OL8
FsMMObkdgE2W6MWN8zXPayvGinx+PYRne9h8WiyJN9N44aG4No0kd4mXPO9vGXAg
8dhNZxKMXmWOqOBcme6aIVGJQtSEEjTl3qqSxYj8kUdIiR4Fznf5cYvjbzSgXRSi
tJdQu5eOk28c99t4TtnLzR1B6qrPDtwjtApoxw5YsjZKbKweOm+DqzhRVSOsoQE5
DC6CFkmdWybz+2O/UNA4qcJIq4bAHYfYskFHkmkIix71YLIthWq6F9+Fpnq8ZQp5
kX+TqxDyAqhirYhl3kJ/DSstpPe+GjebFWPNkvfXxJ8iwnOUqOzuVerpbWFYF8SC
B0lpxMncoJgx5dIM0QRFcw17rv1+GK8Ga0+8avhZ5hqd4raUvxlY7ZInwsMn70sN
Jc2hH70fYF9U3WW4o6p2IY/bh8V0Pu9nMJIILXFuSN7PdcNpSGk3tdQgJ32seAbc
OWfnABEBAAGJAiUEGAECAA8FAmLNircCGwwFCQPCZwAACgkQNQEd08vC4KtZvBAA
kyJd2aNJhpyQQMVZHUdnXwl/W16r+HwO+gg1nXBTj0swNiNKq9mk78IWKJW+XIEC
5RucAq4c2pg8lCHOwuIpPexEKsHTe6PjFnx6DT6ykaZjZQNiPJAl7QoPu0eUGW2L
vBG4/qlJNKzQQQUHBLMV8MlQhNdx5wBbs8s6UGQ0Q+YUzYCBZ4thQb8SfRSNDGc3
0DitLJD+hSJGeDQ38/1brF8hCQuJcOMYpKv7rWDpBDXY0oWhDWCkQo0F4+Ke+8ou
IUMWc/toyhIHcjRP6XpihC2utFfQE4hlugRn2lOI8vkCQkEidXqYZzvfA7zqdmjX
LYWkISsF6jd7tD/ScN8h9KW58Rq/fTiQ5eXsWbV5fY0wMsJJ6uXL/8/yfvJxw/Zp
YkHA+gIMvdmxTxP3qd+W9Hq+vToD8MbGqPFrVb29+xF6VmzB2KFyvNbiGnwSR7Ke
FuFbKkIoly1hlc7s/N1maU2LS4ByvPh0Q6h7AJO7jJL+/wu2kDoQbCLZ85nRGAth
j2b1ZsftaZk4vdZQrRoTovta5gVYJjxMYwFlBqoucXZF3VXoiBz0Hec6Oh9YsK3a
GGO1yxMkDDJPUSl5p43dfJIg9nVvpB37tFp+vn7Ogu01SLYsXChQWdNdw3BQT4pl
Plb3Yd+plt7shbg9LTSafrv7nNukxPzZmVk1FL9w3Ec=
=m5/V
-----END PGP PUBLIC KEY BLOCK-----
```

### Deposit To Card Transfer

#### Introduction

Deposit to card transfer (D2C) is a money transfer from Connecting Party bank account (Deposit) to Receiver bank card number (PAN) or tokenized card data (Card Reference ID). Deposit to card transfer is made in three steps:

Initial payment – any transaction type with present cardholder data will work as initial payment - sale, preauth, transfer, etc. It is important to make the initial payment the most secure way in order to guarantee that a real card holder is registering the card.
 
Card registration – get card-ref-id (Card Reference ID) and register Customer’s card in their profile. Card Reference ID can be used unlimited number of times, while the bank card is active.
 
Money transfer – run v4/transfer-by-ref/ API command using destination-card-ref-id obtained on previous step.
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Deposit To Card Transfer Flow

```plantuml
@startuml

skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer as P
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
hnote over P,B : Initial payment
==Card registration==
A -> B: api/v2/create-card-ref
activate A
activate B
B --> A: Return card-ref-id
deactivate B
A -> A: Assign Card Reference ID to Customer's profile
deactivate A
==Get card info==
group optional
A -> B: api/v2/get-card-info/
activate A
activate B
B -> A: Return Card info
deactivate A
deactivate B
end
==Deposit To Card==
A -> B: api/v4/transfer-by-ref/
activate A
activate B
B --> A: Response with Order ID
B -> B: Process\nDeposit
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate A
deactivate B
end
@enduml
```

(1) To implement Card registration and get Card Reference ID see [/api/v2/create-card-ref](https://doc.payneteasy.com/integration/API_commands/api_v2_create-card-ref.html.md).
 
(3) Connecting Party assigns Card Reference ID to Customer’s profile, after which Connecting Party shows the page saying that the card registration is successful and initial payment approved.
 
(4) To implement Card information request by Card Reference ID see [/api/v2/get-card-info](https://doc.payneteasy.com/integration/API_commands/api_v2_get-card-info.html.md). The contents of response to this request can be used to show information about previously used card to Payer or to update Connecting Party database. This request can be made anytime if Connecting Party has Card Reference ID.
 
(6) Connecting Party initiates deposit to card transfer (D2C). To implement deposit to card request see [/api/v4/transfer-by-ref](https://doc.payneteasy.com/integration/API_commands/api_v4_deposit_transfer.html.md)
 
(9) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(11) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(12) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.

### Direct Bank transfer

#### Introduction

A Direct Bank transfer is an international bank transfer made via the Swift network. This method allows to process bank transfers using the Direct method (with direct transfer of the Payer’s bank data).
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Direct Bank Transfer Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/bank-wire-transfer/
activate B
B --> A: Order ID
B -> B: Process\nBank Wire Transfer
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement bank wire transfer request see [/api/v2/bank-wire-transfer/](https://doc.payneteasy.com/integration/API_commands/api_v2_bank-wire-transfer.html.md).
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### e Check Sale

#### Introduction

Payneteasy allows Connecting Party to accept electronic check payments for goods and services purchased via e-commerce websites. An electronic check works much like a regular check, only instead of using a paper check to provide their bank account, routing number and payment authorization, the Payer provides Connecting Party with the necessary payment information through other methods, allowing the Connecting Party to process the information electronically.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### e Check Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/sale-echeck/
activate B
B --> A: Order ID
B -> B: Process\nSale-eCheck
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement sale-e Check request see [/api/v2/sale-echeck/](https://doc.payneteasy.com/integration/API_commands/api_v2_sale-echeck.html.md).
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### FAQ

#### Gather useful information

Please gather this information and provide it to support to quickly resolve issues which happened during the integration
 
 
> - Please indicate whether sandbox or production environments were used.
> - Please indicate whether or not the functionality worked at one time or not. If so, please indicate since when it stopped working.
> - Please add relevant log information ( orderid, serial-number, client_orderid, ENDPOINTID, ENDPOINTGROUPID) when any is available.

#### Frequently asked questions during the integration

##### What does INVALID_CONTROL_CODE error mean?

The calculation of the signature may be different for different types of API calls. The most common reasons are:
 
> - Wrong credentials. Check credentials received from Payment Gateway manager.
> - API calls to sandbox had production environment URL or vise versa.
> - Production credentials (ENDPOINTID, ENDPOINTGROUPID, control key, etc) were used on sandbox or vise versa.
> - Parameters for signature calculation are in incorrect order.
> - The amount of the transaction is not converted to minimal decimal units.
The best way to check signature calculation is to use the request builder sections in API documentation:
 
> - Choose the correct URL from the combobox with API calls selection, if present.
> - After pressing the Sign button, please check signature value for the String to sign whether the same string is being signed or not.
> - If the signing string looks correct, signature value must be the same as in Signature field.
> - Login to UI and find the particular API requests and responses on the Integration panel screen in Tools section.

##### What is the difference between ENDPOINTID or ENDPOINTGROUPID?

Payneteasy gateway can support any currency.
 
> - ENDPOINTID supports only one currency.
> - ENDPOINTGROUPID can support as many currencies as needed. Full list of currencies should be sent to Payment Gateway manager for project configuration.
Due to the different nature of these two entities it is impossible to use ENDPOINTID instead of ENDPOINTGROUPID and vise versa.
 

##### Is it possible to use Synchronous API?

All APIs are asynchronous, see [Async-Response](https://doc.payneteasy.com/integration/general_api_usage/async_response.html.md). If using synchronous API is required, it should be implemented on Connecting Party side. Ask Payment Gateway manager to refine if it is possible to make synchronous calls in your integration.
 

##### How to implement 3-D Secure (Verified by Visa / Master Card Secure Code) on Native mobile app?

Even in native app embedded Web View component should be used in order to open banking ACS server URL.
 
To process the transactions without redirect to 3-D Secure page Connecting Party’s application must meet the following requirements:
 
> - Payers are identified and there is a low fraud probability, it this case Connecting Party can ask Payment Gateway manager to open non3D account.
> - Connecting Party have PCI DSS certificate and can gather cardholder data on their side, in this case Connecting Party can ask Payment Gateway manager to open account with Direct API support to avoid unnecessary redirects.

##### What is client_orderid?

This transaction identifier is generated on Connecting Party side. It is also referred as merchant-order-id in some APIs.
 

##### How to get an approved transaction on sandbox environment?

For different types of API Payneteasy have different mechanisms for getting approved transactions and transactions in other statuses. For e-commerce transactions Payneteasy is using different CVVs, see [test_cards](https://doc.payneteasy.com/integration/general_api_usage/test_scenarios.html.md). For mPOS transactions see [mpos](https://doc.payneteasy.com/integration/mpos_api_index.html.md).
 

##### Why response is formatted with (0xA)?

To improve readability of the response in most APIs, Payneteasy adds (0xA) character at the end of each parameters value. To process the response from the Payment Gateway please, implement the handling mechanism for this character.
 

##### Is it possible to use redirect_url to get transaction status for backoffice?

It is not advisable.
 
All parameters for the final redirect are passed through the customer’s browser. Parameters can be lost during the transmission over the internet. To get guaranteed result from Payneteasy gateway see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 

##### Is it possible to use GET instead of POST to submit data to Payneteasy gateway?

Unfortunately it is not possible.
 
Transmitting parameters using HTTP GET is strictly forbidden to avoid possible data leaks.
 

##### What does INVALID_CALLBACK_URL mean?

Please use full public URL with http:// or https://
 
For example, please pass [http://www.example.com](http://www.example.com) or [https://www.example.com](https://www.example.com) instead of www.example.com. Only following ports are allowed:
 
> - 80, 8080 for HTTP
> - 443, 8443 for HTTPS

##### How often can transaction status be polled?

Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
Normally it takes up to 5 seconds to process the non3D transaction and up to 60 minutes for 3D transaction. Transactions made via some payment methods or payment channels, especially processed in offline mode, might stay in non-final status for several hours or even days, so there is no point in polling transaction status often for such cases. Connecting Party should rely on callback to get transaction final status, see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 

##### Why transaction has been declined with base 64 fail reason?

Please use urldecode to process html parameter in Payneteasy gateway response.
 
Payneteasy is trying to help Connecting Party to correctly handle API responses. Base64 test gives Connecting Party an ability to check if 3DS page provided by bank will be correctly handled on production environment. If Connecting Party is getting this error, this means that urldecode probably was not used to parse the Payneteasy gateway response or probably it works in incorrect way (for example in some versions of PHP it is needed to use rawurldecode instead).

### Final Redirect

#### Final Redirect Parameters

Final redirect to merchant (represented by Connecting Party) website is performed when Payer ends payment flow. Final redirect is initiated from within Payer’s browser using HTTP POST method.

| Redirect parameter name | Description |
|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| orderid | Order id assigned to the order by gate.payneteasy.eu. |
| merchant_order | Connecting Party order id. |
| client_orderid | Connecting Party order id. |
| error_message | If status is declined or error this parameter contains the reason for decline or error details. |
| control | Checksum used to ensure that it is gate.payneteasy.eu (and not a fraudster) that initiates the request. This is SHA-1 checksum of the concatenation status + orderid + client_orderid + merchant-control. |
| descriptor | Gate descriptor. |
| processor-tx-id | Acquirer transaction identifier. |
| amount | Actual transaction amount. |
| bin | Bank BIN of customer credit card number. |
| type | The type of response. |
| card-type | Type of customer credit card. |
| phone | Customer phone. |
| last-four-digits | Last four digits of customer credit card number. |
| card-holder-name | Cardholder name. |
| error_code | Error Code. |

Connecting Party should not use Payer redirect as a main source of information about transaction’s final status. If Connecting Party has passed server_callback_url in initial transaction request, Payment Gateway will call this URL. Connecting Party may use it for custom processing of the transaction completion, e.g. to collect sales data in Connecting Party database. The parameters sent to this URL are specified in [Connecting Party Callbacks](https://doc.payneteasy.com/integration/merchant_callback_parameters.html.md).

#### Final Redirect Request Example

Payment Gateway sends POST redirect to https://connectingparty.com/pay/redirect?token=some_token with params in x-www-form-urlencoded format:

```http
error_message=null
&processor-tx-id=PNTEST-1788082
&amount=100.00
&merchant_order=test
&orderid=1788082
&client_orderid=test
&bin=444455
&control=854f38715ee6bf43fa18e3ca202985a06e0ae755
&gate-partial-reversal=enabled
&descriptor=DEMO1
&gate-partial-capture=enabled
&type=sale
&card-type=VISA
&phone=%2B31201112233
&last-four-digits=1111
&card-holder-name=TEST+HOLDER
&status=approved
```

### Fiscalization service

#### Overview

Fiscalization service is used for registration of financial cheques and invoices in Payneteasy payment gateway and their further processing. Fiscalization is supported for both initial and recurring Sale and Preauth transactions, via Server-To-Server or Form integration. See the suitable integration scenario in respective Use-Cases or ask support manager for details. Transaction with cheque/invoice is processed by Payneteasy Payment Gateway with additional requests for tax accounting.
 

#### Fiscalization service parameter (cheque)

In order to initiate a transaction with the use of fiscalization service, Connecting Party sends an HTTPS POST request for sale or preauth transaction with additional parameter.
 

| Request Parameters | Type | Comment |
|----------------------|-------------|-----------------------------------------------------------------------------------|
| cheque | Json string | Financial cheque or invoice. Mandatory for transaction request with Fiscalization |

#### Json string structure for cheque parameter

A simple json string example for cheque parameter:
 
```http
{
  "cheque_type" : 1,
  "tax_system" : 1,
  "positions" : [
    {
      "quantity" : 2,
      "price" : 322.94,
      "tax" : 4,
      "description" : "Product/Service 1"
    },
    {
      "quantity" : 1,
      "price" : 500,
      "tax" : 4,
      "description" : "Product/Service 2"
    }
  ]
}
```

Json string parameters:
 

| Parameter | Type | Comment | Possible values |
|-------------|-------------|--------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| cheque_type | Decimal | Calculation type/sign | 0 - income, 1 - expense, 2 - return of income, 3 - return of expense |
| tax_system | Decimal | Tax system | 0 - General taxation system, 1 - Simplified income taxation system, 2 - Simplified income minus expense taxation system, 3 - Unified tax on imputed income, 4 - Unified agricultural tax, 5 - Patent system of taxation |
| positions | Array | Array of products/services | Array of products/services |
| quantity | Decimal | Quantity of product/service | |
| price | Decimal | Price per product/service considering discounts and mark-ups | |
| tax | Decimal | value-added tax | 1 - 22% value-added tax, 2 - 10% value-added tax, 3 - 0% value-added tax, 4 - without value-added tax, 5 - 22/122 value-added tax, 6 - 10/110 value-added tax |
| description | String(128) | Description of product/service | |

> **Note:** Please take into consideration that the total price of all products/services which are provided in positions array should be equal to amount parameter value of sale request.

#### Example of transaction request with fiscalization

This example of Server-To-Server Sale request body with fiscalization displays how to correctly include the cheque parameter. Response example is provided in relevant API command documentation.
 
```http
client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=%2B12063582043
&cell_phone=%2B19023384543
&amount=700.00
&email=john.smith@gmail.com
&currency=USD
&ipaddress=65.153.12.232
&site_url=www.google.com
&credit_card_number=4538977399606732
&card_printed_name=CARD HOLDER
&expire_month=12
&expire_year=2099
&cvv2=123
&purpose=user_account1
&redirect_url=https://doc.payneteasy.com/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&cheque={ "cheque_type" : 1, "tax_system" : 1, "positions" : [ { "quantity" : 2, "price" : 100.00, "tax" : 4, "description" : "Product/Service 1" }, { "quantity" : 1, "price" : 500, "tax" : 4, "description" : "Product/Service 2" } ] }
&control=768eb8162fc361a3e14150ec46e9a6dd8fbfa483
```

### Forms Customization

#### Payment Page Display Logic

```plantuml
  skinparam ConditionEndStyle hline
  : (1) Initiate transaction;
  if ((2) Additional Payer input required?) then (yes)
  : (3) return input form;
  : (4) submit form;
  else (no)
  endif
  if ((5) External form required?) then (yes)
  : (6) request external form from the payment provider;
  : (7) redirect to external form;
  : (8) submit form on payment provider side;
  else (no)
  endif
  : (9) show wait form;
  : (10) process transaction;
  : (11) show finish form or redirect \nto Connecting Party website;
```

(1) Transactions can be initiated with API requests, batch upload or via Virtual terminal on UI. Each payment method has its own payment page display logic.
 

> **Note:** Payment Cashier might have multiple transactions initiated within the same payment session, because it can have multiple payment methods available for the Payer. When Payer selects payment tab, respective auxiliary transaction is initiated. See [Payment Cashier Page Customization](#payment-cashier-page-customization-reference).

(3) For credit card payment method form is displayed on Payment Gateway side and can be customized. See [Payment Page Customization](#payment-page-customization-reference). Some other payment methods may have additional forms on Payment Gateway side. Contact Payneteasy support for details.
 
(7) Some payment methods require the Payer to be redirected to their own form. That form is not hosted by Payment Gateway and can\`t be customized.
 
(9) Until transaction reaches final status, Payment Gateway displays [Wait Form](#wait-page-customization-reference) for the Payer.
 
(11) After the transaction reaches the final status, Payment Gateway displays [Finish Form](#finish-page-customization-reference) for the Payer or [Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md) to Connecting Party website.
 

#### Payment Page Customization

##### Payment Page Example

```html
<html>
<head>
<script type="text/javascript">
  function isCCValid(r){var n=r.length;if(n>19||13>n)return!1;
    for(i=0,s=0,m=1,l=n;i<l;i++)d=parseInt(r.substring(l-i-1,l-i),10)*m,s+=d>=10?d%10+1:d,1==m?m++:m--;
    return s%10==0?!0:!1}
</script>
</head>
<body>
<h3>Order #$!MERCHANT_ORDER_ID - $!ORDERDESCRIPTION</h3>
<h3>Total amount: $!AMOUNT $!CURRENCY to $!MERCHANT</h3>
<form action="${ACTION}" method="post">
  <div>Cardholder name: <input name="${CARDHOLDER}" type="text" maxlength="64"/></div>
  <div><label for="cc-number">Credit Card Number</label> <input id="cc-number" name="${CARDNO}" type="text" maxlength="19" autocomplete="cc-number"/></div>
  <div>Card verification value: <input name="${CVV2}" type="text" maxlength="4" autocomplete="off"/></div>

    Expiration date:
    <select class="expiry-month" name="${EXPMONTH}" size="1" autocomplete="cc-exp-month" >
      <option value="01">January</option><option value="02">February</option><option value="03">March</option>
      <option value="04">April</option><option value="05">May</option><option value="06">June</option>
      <option value="07">July</option><option value="08">August</option><option value="09">September</option>
      <option value="10">October</option><option value="11">November</option><option value="12">December</option>
    </select>
      <select class="expiry-year" id="cc-exp-year" name="${EXPYEAR}" size="1" autocomplete="cc-exp-year">
      ${EXPIRE_YEARS}
    </select>

  <div><label for="dest-number">Destination card number:</label> <input id="dest-number" name="${DESTINATIONCARDNO}" type="text" maxlength="19" autocomplete="off"/></div>
  $!{INTERNAL_SECTION}
  #if($!card_error)
  <div style="color: red;">$!card_error</div>
  #end
  <input name="submit" onclick="return isCCValid(document.getElementById('cardnumber').value);" type="submit" value="Pay"/>
</form>
</body>
</html>
```

> **Note:** The code described below allows to submit destination card data in [Transfer](https://doc.payneteasy.com/integration/api_use_cases/transfer_form.html.md) type transactions:

```html
<div><label for="dest-number">Destination card number:</label>
<input id="dest-number" name="${DESTINATIONCARDNO}" type="text" maxlength="19" autocomplete="off"/></div>
```

##### Payment Page Autofill

If Connecting Party wants to use autofill in payment form, certain element attributes <id> <autocomplete> <label for> should be hardcoded in the following manner:

```html
<label for="cc-number">Credit Card Number</label><span class="form-label-comment">The 13-19 digits on the front of your card</span>
<input class="card-number-field" id="cc-number" name="${CARDNO}" type="text" maxlength="19" autocomplete="cc-number" />
```

If autofill in the transfer form must be used, certain element attributes <id> <autocomplete> <label for> should be hardcoded in the following manner:

```html
#if ($INPUT_SOURCE_CARD_CARDHOLDER)

<li class="form-li">
    <label class="form-label" for="cc-name">Card printed name:</label>
    <input class="form-name-field" id="cc-name" name="${CARDHOLDER}" type="text" maxlength="50" autocomplete="cc-name" value="${CARDHOLDER_VALUE}"/>
</li>
#end
#if ($INPUT_SOURCE_CARD_CVV2)

<li class="form-li">
    <label class="form-label" for="${CVV2}">Card security code (CVV2/CVC2):</label>
    <input class="form-cvv-field" name="${CVV2}" id="${CVV2}" type="password" maxlength="4" autocomplete="off"/>
</li>
#end
#end
#if ($INPUT_DESTINATION_CARD)

#if($!DESTINATIONCARDNO)
<li class="form-li">
    <label class="form-label" for="${DESTINATIONCARDNO}">Destination card number:</label>
    <input class="form-number-field" id="${DESTINATIONCARDNO}" name="${DESTINATIONCARDNO}" type="text" maxlength="19" autocomplete="off"/>
</li>
#end
#end
```

Payneteasy has default payment form template which supports autocomplete. In case if Connecting Party wants to add additional fields for autocomplete, this [specification](https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#autofill/) should be used for naming references.

##### Payment Page Template Macros

| Field Name Macro | Field Value Macro | Description |
|---------------------------------|---------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ${APPLE_PAY} | n/a | Apple Pay buy button will be available if this macros is used. Not available for Transfer transactions. |
| ${GOOGLE_PAY} | n/a | Google Pay buy button will be available if this macros is used. Not available for Transfer transactions. |
| ${CARDNO} | ${CARDNOVALUE} | Payer’s credit card number. |
| ${EXPMONTH} | n/a | Credit card expiration month. |
| ${EXPYEAR} | n/a | Credit card expiration year. |
| ${CVV2} | ${CVV2VALUE} | Card security code. Example: 432 |
| ${CARDHOLDER} | ${CARDHOLDER_VALUE} | Card printed name. |
| ${MERCHANT} | n/a | End point display name. |
| ${SKIN_VERSION} | n/a | CSS skin version. |
| ${ORDERDESCRIPTION} | n/a | Order description. |
| ${CUSTOMER_FIRST_NAME} | n/a | Payer first name sent by Connecting Party via input parameters. |
| ${CUSTOMER_LAST_NAME} | n/a | Payer last name sent by Connecting Party via input parameters. |
| ${CUSTOMER_EMAIL} | n/a | Payer E-mail address sent by Connecting Party via input parameters. |
| ${DESTINATIONCARDNO} | n/a | Destination credit card number. Available for Transfer transactions. |
| ${DESTINATION_CARD_TYPE} | n/a | Destination card type. Available for Transfer transactions. |
| ${DESTINATION_LAST_FOUR_DIGITS} | n/a | Destination card last four digits. Available for Transfer transactions. |
| ${AMOUNT} | n/a | Amount. |
| ${CURRENCY} | n/a | Currency. |
| ${DESTINATION_PURPOSE} | n/a | Purpose sent by Connecting Party via input parameters. |
| ${PAYNET_ORDER_ID} | n/a | Payneteasy order id. |
| ${MERCHANT_ORDER_ID} | n/a | Connecting Party order id. |
| ${refresh_interval} | n/a | Refresh interval recommended by system. |
| ${uuid} | n/a | Internal. |
| ${INTERNAL_SECTION} | n/a | Internal for i Frame integration. |
| ${CUSTOMER_IP_COUNTRY_ISO_CODE} | n/a | Payer country defined by IP Address. |
| ${PREFERRED_LANGUAGE} | n/a | Payer language sent by Connecting Party via input parameters. Not available for Account Verification. |
| ${BROWSER_LANGUAGE} | n/a | Payer language defined by browser settings. |
| ${CUSTOMER_LANGUAGE} | n/a | Payer language send by Connecting Party via input parameters or defined by browser settings if first is not set. |
| ${MERCHANT_FORM_DATA} | n/a | Parameters sent in MERCHANT_FORM_DATA API parameter are parsed into macros with the same name, the parameter is url-encoded, example: testparam%3Dtest1%26mynewparam%3Dtest2 and is parsed into $MFD_testparam = test1 and $MFD_mynewparam = test2 macros in the form. Parameter name characters[a-zA-Z0-9], parameter value characters[a-zA-Z0-9], only characters = and & are allowed as control characters, 2MB max size. Not available for Account Verification. For example, this parameter can be used to display payment form in light/dark mode depending on the value passed by Connecting Party (e.g. pass merchant_form_data=theme%3Ddark in request and $MFD_theme macro placeholder on payment form will be changed to dark. |
| ${MIN_AMOUNT} | n/a | This macro has the value provided in minimum-transaction-amount parameter in initial request. It can be used to validate the transaction amount before payment form is submitted. Contact support manager to enable this feature. |
| ${MAX_AMOUNT} | n/a | This macro has the value provided in maximum-transaction-amount parameter in initial request. It can be used to validate the transaction amount before payment form is submitted. Contact support manager to enable this feature. |
| ${CUSTOMER_ZIP_CODE} | n/a | Generates a ZIP code if it was not received from the Payer. Not available for Account Verification. |

#### Prefilled Cardholder Data in Payment Page

Payer’s cardholder data, used for processing of a previous transaction, can be tokenized for future use with request to [/api/v2/create-card-ref/](https://doc.payneteasy.com/integration/API_commands/api_v2_create-card-ref.html.md). The obtained token cardrefid then can be passed in the next requests to relevant API. If this parameter is sent, all cardholder data input will be immutable and prefilled on the payment page. CVV is not tokenized and must be provided by Payer on this payment page. Below is the example of form customization to work with prefilled cardholder data in payment page.

> **Note:** This feature is available only for [Sale](https://doc.payneteasy.com/integration/api_use_cases/sale_form.html.md) and [Preauth](https://doc.payneteasy.com/integration/api_use_cases/preauth_form_capture_and_cancel.html.md) transaction types and cannot be used in [Payment Cashier](https://doc.payneteasy.com/integration/api_use_cases/payment_cashier.html.md).

##### Prefilled Cardholder Data Payment Page Example

```html
<html>
<head>
</head>
<body>
  <h3>Order #$!MERCHANT_ORDER_ID - $!ORDERDESCRIPTION</h3>
  <h3>Total amount: $!AMOUNT $!CURRENCY to $!MERCHANT</h3>
  <h4>Card Holder: ${CARDHOLDER} </h4>
  <h4>Card Number: $!CARD_BIN ...... $!CARD_LAST4DIGITS </h4>
  <h4>Exp year: $!EXPYEAR_VALUE </h4>
  <h4>Exp month: $!EXPMONTH_VALUE </h4>
  <form action="${ACTION}" method="post">
    <div>Cvv: <input name="${CVV2}" type="text" maxlength="4" autocomplete="off"/></div>
    $!{INTERNAL_SECTION}
    #if($!card_error)
      <div style="color: red;">$!card_error</div>
    #end
    <input name="submit" type="submit" value="Pay"/>
  </form>
</body>
</html>
```

##### Prefilled Cardholder Data Payment Page Macros

| Field Name Macro | Field Value Macro | Description |
|---------------------|---------------------|----------------------------|
| ${CARDHOLDER} | n/a | Cardholder name. |
| ${CARD_BIN} | n/a | Full card number. |
| ${CARD_LAST4DIGITS} | n/a | Last 4 digits of the card. |
| ${EXPMONTH_VALUE} | n/a | Card expiry month value. |
| ${EXPYEAR_VALUE} | n/a | Card expiry year value. |
| ${CVV2} | n/a | CVV2 card value. |

#### Wait Page Customization

##### Wait Page Template

Wait Page is the form where the Payer’s stays on until transaction reaches it’s final status.

```html
<html>
<head>
    <script type="text/javascript">
      function fc(t) {
        document.getElementById("seconds-remaining").innerHTML = t;
        (t > 0) ? setTimeout(function(){fc(--t);}, 1000) : document.checkform.submit();}
    </script>
</head>
<body onload="fc($!refresh_interval)">
    <h3>Order #$!MERCHANT_ORDER_ID - $!ORDERDESCRIPTION</h3>
    <h3>Total amount: $!AMOUNT $!CURRENCY to $!MERCHANT</h3>
    Please wait, your payment is being processed, remaining <span id="seconds-remaining">&nbsp;</span> seconds.
    <form name="checkform" method="post">
        <input type="hidden" name="tmp" value="$!uuid"/>
        $!{INTERNAL_SECTION}
        <input type="submit" value="Check" />
    </form>
</body>
</html>
```

> **Note:** The code described below do not regard to the [Account Verification](https://doc.payneteasy.com/integration/api_use_cases/account_verification_form.html.md):

```html
<h3>Total amount: $!AMOUNT $!CURRENCY to $!MERCHANT</h3>
```

##### Wait Page Template Macros

| Field Name Macro | Field Value Macro | Description |
|---------------------------------|---------------------|------------------------------------------------------------------------------------------------------------------|
| $!refresh_interval | n/a | Refresh interval recommended by system. |
| $!MERCHANT_ORDER_ID | n/a | Connecting Party order id. |
| $!ORDERDESCRIPTION | n/a | Order description. |
| $!AMOUNT | n/a | Amount. Not available for Account verification. |
| $!CURRENCY | n/a | Currency. Not available for Account verification. |
| $!MERCHANT | n/a | End point display name. |
| $!uuid | n/a | Internal. |
| $!{INTERNAL_SECTION} | n/a | Internal for i Frame integration. |
| ${SKIN_VERSION} | n/a | CSS skin version. |
| ${PAYNET_ORDER_ID} | n/a | Payneteasy order id. |
| ${CUSTOMER_IP_COUNTRY_ISO_CODE} | n/a | Payer country defined by IP Address. |
| ${PREFERRED_LANGUAGE} | n/a | Payer language send by Connecting Party via input parameters. |
| ${BROWSER_LANGUAGE} | n/a | Payer language defined by browser settings. |
| ${CUSTOMER_LANGUAGE} | n/a | Payer language send by Connecting Party via input parameters or defined by browser settings if first is not set. |

#### Finish Page Customization

##### Finish Page Template

A form on which the Payer is shown the [final status](https://doc.payneteasy.com/integration/statuses.html.md) of his request.

```html
<html>
    <head>
    </head>
    <body>
        <h3>Processing of the payment has finished</h3>
        <h3>Order Invoice: $!{MERCHANT_ORDER_ID}</h3>
        <h3>Order ID: $!{PAYNET_ORDER_ID}</h3>
        <h3>Status: $!{STATUS}</h3>
        #if($ERROR_MESSAGE)
            <h3>Error: $!{ERROR_MESSAGE}</h3>
        #end
    </body>
</html>
```

##### Finish Page Macros

| Field Name Macro | Field Value Macro | Description |
|---------------------------------|---------------------|------------------------------------------------------------------------------------------------------------------|
| ${STATUS} | n/a | Order status. |
| ${PAYNET_ORDER_ID} | n/a | System order id. |
| ${MERCHANT_ORDER_ID} | n/a | Connecting Party order id. |
| ${ERROR_MESSAGE} | n/a | Contains the reason for decline or error details. |
| ${SKIN_VERSION} | n/a | CSS skin version. |
| ${CUSTOMER_IP_COUNTRY_ISO_CODE} | n/a | Payer country defined by IP Address. |
| ${PREFERRED_LANGUAGE} | n/a | Payer language send by Connecting Party via input parameters. |
| ${BROWSER_LANGUAGE} | n/a | Payer language defined by browser settings. |
| ${CUSTOMER_LANGUAGE} | n/a | Payer language send by Connecting Party via input parameters or defined by browser settings if first is not set. |
| ${AMOUNT} | n/a | Amount. Not available for Account verification. |
| ${CURRENCY} | n/a | Currency. Not available for Account verification. |
| ${DESCRIPTION} | n/a | Transaction description. Not available for Account verification. |
| ${DATE} | n/a | Transaction date. Not available for Account verification. |
| ${PAYNET_PROCESSING_DATE} | n/a | Payneteasy processing date. Not available for Account verification. |
| ${RRN} | n/a | Retrieval Reference Number. Not available for Account verification. |
| ${AUTH_CODE} | n/a | Authorization Code. Not available for Account verification. |
| ${CARD_TYPE} | n/a | Card type. Not available for Account verification. |
| ${LAST_FOUR_DIGITS} | n/a | Last four digits of a card. Not available for Account verification. |
| ${CUSTOMER_REDIRECT_URL} | n/a | URL the cardholder will be redirected to upon completion of the transaction. |

#### Payment Cashier Page Customization

> **Note:** This page is relevant only for [Payment Cashier](https://doc.payneteasy.com/integration/api_use_cases/payment_cashier.html.md) integration.

##### Parallel Form Template Sample

Parallel Form is a form for the Payer to select one of the available payment methods to perform a transaction.

```http
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
</head>
<body>

<span id="countryIsoCode" style="display: none;">$!CUSTOMER_IP_COUNTRY_ISO_CODE</span>

    <input name="customer_language_code" id="iso" type="hidden" value="$CUSTOMER_LANGUAGE"/>
    #if (!$HAS_PARALLEL_FORM_PAYMENT_METHODS)
        <select id="countrySelector" onchange="onCountrySelected(this);">
            <option value="EU">Europe</option>
            
        </select>
    #end
    #if ($HAS_PARALLEL_FORM_PAYMENT_METHODS)

            <ul id="formTabs" class="form-tabs-ul">
                #foreach ($paymentMethod in $PARALLEL_FORM_PAYMENT_METHODS)
                    <li id="$!{paymentMethod.identifier}-FORM-button" class="form-tab-button#if($velocityCount == 1) form-tab-button-active form-tab-button-active-$!{paymentMethod.identifier}#end" #if($paymentMethod.iframe) onclick="chooseIframe('$!{paymentMethod.identifier}');" #end>
                        $!{paymentMethod.name}
                    </li>
                #end
            </ul>
            <select id="countrySelector" onchange="onCountrySelected(this);">
                <option value="EU">Europe</option>
                
            </select>

    #foreach ($paymentMethod in $PARALLEL_FORM_PAYMENT_METHODS)
        <div class="ssl-header ssl-header-$!{paymentMethod.identifier}" id="merchant-description-$!{paymentMethod.identifier}" #if ($velocityCount> 1) style="display: none;"#end>
            <span class="ssl-text">${MERCHANT}</span>

                <span class="flag-EN" id="flag-$!{paymentMethod.identifier}"></span>
                <select id="langSelector-$!{paymentMethod.identifier}" class="langSelector langSelector-$!{paymentMethod.identifier}" onchange="selectLang('$!{paymentMethod.identifier}');">
                    <option value="EN">English</option>
                    
                </select>

        <script>
            merchantDescriptionIds.push("merchant-description-$!{paymentMethod.identifier}");
            paymentMethodsCountries["$!{paymentMethod.identifier}"] = "$!{paymentMethod.countries}";
        </script>
    #end
    #end
    #if ($HAS_PARALLEL_FORM_PAYMENT_METHODS)
        #foreach ($paymentMethod in $PARALLEL_FORM_PAYMENT_METHODS)
            #if ($paymentMethod.iframe)
                <div class="frame-container-$!{paymentMethod.identifier} payment-method-iframe" id="$!{paymentMethod.identifier}-FORM" pneopen="#if ($velocityCount == 1)true#{else} false#end" pnesrc="$!paymentMethod.initSessionUrl" #if ($velocityCount> 1) style="display: none;"#end>
                    <iframe src="#if ($velocityCount == 1)$!paymentMethod.initSessionUrl#end" scrolling="#if $!{paymentMethod.identifier} == 'QIWI' || $!{paymentMethod.identifier} == 'ASTROPAY')yes#{else}no#end">
                    </iframe>

            #end
        #end
        <form id="waitForm" action="$!WAIT_FORM_URL">
            #foreach( $p in $WAIT_FORM_PARAMETERS )
                <input type="hidden" name="$p.key" value="$!p.value">
            #end
            
        </form>
    #end

</body>
</html>
```

For more information see [Country Codes](https://doc.payneteasy.com/integration/country_codes.html.md) and [Language Codes](https://doc.payneteasy.com/integration/language_codes.html.md).

##### Parallel Form Macros

| Field Name Macro | Field Value Macro | Description |
|------------------------------------|---------------------|------------------------------------------------------------------------------------------------------------------|
| $!CUSTOMER_IP_COUNTRY_ISO_CODE | n/a | Payer\`s country defined by IP Address. |
| $!CUSTOMER_COUNTRY_CODE | n/a | Billing country of customer sent in incoming API request. |
| $CUSTOMER_LANGUAGE | n/a | Payer language sent by Connecting Party via input parameters or defined by browser settings if first is not set. |
| $HAS_PARALLEL_FORM_PAYMENT_METHODS | n/a | Determines the availability of parallel form payment methods. |
| $payment Method | n/a | Payment method object. |
| $PARALLEL_FORM_PAYMENT_METHODS | n/a | Array with available parallel form payment methods. |
| $!{payment Method.identifier} | n/a | Payment method identifier. |
| $velocity Count | n/a | Sequence number of the payment method. |
| $payment Method.iframe | n/a | Iframe of payment method. |
| $!{payment Method.name} | n/a | Payment method name. |
| ${MERCHANT} | n/a | End point display name. |
| $!{payment Method.countries} | n/a | Countries which are set for this payment method. |
| $$!payment Method.init Session Url | n/a | URL for payment method session initialization. |
| $!WAIT_FORM_URL | n/a | Waiting form URL. |
| $p | n/a | Waiting form parameter. |
| $WAIT_FORM_PARAMETERS | n/a | Waiting form parameters array. |
| $p.key | n/a | Waiting form parameter key. |
| $!p.value | n/a | Waiting form parameter value. |
| $!{INTERNAL_SECTION} | n/a | Internal for i Frame integration. |

##### Parallel Form Scripts

The following Parallel Form scripts are required for it\`s operating. The first script should be added into <head> tag of html document:

```html
<script type="text/javascript">
var merchantDescriptionIds = [];
var paymentMethodsCountries = {};
function isCCValid(r) {
    var n = r.length;
    if (n > 19 || 13 > n) return !1;
    for (i = 0, s = 0, m = 1, l = n; i < l; i++) d = parseInt(r.substring(l - i - 1, l - i), 10) * m, s += d >= 10 ? d % 10 + 1 : d, 1 == m ? m++ : m--;
    return s % 10 == 0 ? !0 : !1
}

function runPayment(t) {
    if (isCCValid(t)) {
        return !0;
    } else {
        document.getElementById('cardnumber').style.borderColor = '#fb860f';
        return !1;
    }
}

function chooseIframe(paymentMethodName) {
    var id = paymentMethodName + '-FORM';
    var iframes = document.getElementsByTagName('IFRAME');
    for (var i = 0; i < iframes.length; i++) {
        var iframe = iframes[i].parentNode;
        var isCurrent = iframe.id == id;
        iframe.style.display = isCurrent ? 'block' : 'none';
        if (isCurrent && iframe.getAttribute("pneopen") == 'false') {
            iframe.firstElementChild.src = iframe.getAttribute("pnesrc") + "?country=" + document.getElementById("countryIsoCode").innerText;
            iframe.setAttribute("pneopen", 'true');
        }
        var buttonElem = document.getElementById(iframe.id + '-button');
        buttonElem.className = (iframe.id == id) ? 'form-tab-button form-tab-button-active form-tab-button-active-' + paymentMethodName : 'form-tab-button';
    }
    var descriptionId = 'merchant-description-' + paymentMethodName;
    for (var i = 0; i < merchantDescriptionIds.length; i++) {
        var isCurrent = merchantDescriptionIds[i] == descriptionId;
        document.getElementById(merchantDescriptionIds[i]).style.display = isCurrent ? 'flex' : 'none';
    }
}

function pneInit() {
    window.pneMasterSessionProcessed = function() {
        document.getElementById('waitForm').submit()
    }
    foreach( $paymentMethod in $PARALLEL_FORM_PAYMENT_METHODS )
        if( $paymentMethod.default )chooseIframe('$!{paymentMethod.identifier}-FORM');
        break
    end
    end
}
</script>
```

Second script should be added to html code before the </body> close tag.

```html
<script type="text/javascript">
function updateTabsVisibility() {
    var countryCode = getSelectedCountryCode();
    var paymentMethods = getPaymentMethods();
    var someIframeShown = false;
    for (var i = 0; i < paymentMethods.length; i++) {
        var paymentMethod = paymentMethods[i];
        var visible = isPaymentMethodVisible(paymentMethod, countryCode);
        updateTabVisibility(paymentMethod, visible);
        if (visible && !someIframeShown) {
            chooseIframe(paymentMethod);
            someIframeShown = true;
        }
    }
}

function getSelectedCountryCode() {
    return document.getElementById('countryIsoCode').innerText;
}

function setSelectedCountryCode(countryCode) {
    document.getElementById('countryIsoCode').innerText = countryCode;
}

function getPaymentMethods() {
    var lis = document.getElementById("formTabs").children;
    var result = [];
    for (var i = 0; i < lis.length; i++) {
        var li = lis[i];
        var id = li.id;
        if (id != null) {
            result.push(id.substring(0, id.indexOf("-FORM-button")));
        }
    }
    return result;
}

function isPaymentMethodVisible(paymentMethodId, countryCode) {
    if (paymentMethodsCountries[paymentMethodId] == "") {
        return true;
    } else {
        return paymentMethodsCountries[paymentMethodId].indexOf(countryCode) > -1;
    }
}

function updateTabVisibility(paymentMethod, visible) {
    document.getElementById(paymentMethod + '-FORM-button').style.display = visible ? 'inline-block' : 'none';
}

function onCountrySelected(selector) {
    setSelectedCountryCode(selector.value);
    updateTabsVisibility();
}

document.addEventListener('DOMContentLoaded', function() {
    pneInit();
    updateTabsVisibility();
    document.getElementById('countrySelector').value = getSelectedCountryCode();
});

function syncLangSelectors(ISO) {
    var methods = getPaymentMethods();
    for (var i = 0; i < methods.length; i++) {
        document.getElementById('flag-' + methods[i]).className = "flag-" + ISO;
        document.getElementById('langSelector-' + methods[i]).value = ISO;
    }
}

var ISO = document.getElementById('iso').value.toUpperCase();
ISO = 'EN';
document.getElementById('iso').value = ISO;
syncLangSelectors(ISO);

document.addEventListener('DOMContentLoaded', function() {
    //l10n();
});

function selectLang(method) {
    var ISO = document.getElementById('langSelector-' + method).value.toUpperCase();
    document.getElementById('iso').value = ISO;

    syncLangSelectors(ISO);
    //l10n();
}
</script>
```

If needed to determine the Payer billing country on the data sent via the API, $!CUSTOMER_COUNTRY_CODE is used. If needed to determine the Payer billing country on the IP address from the Payer browser, use $!CUSTOMER_IP_COUNTRY_ISO_CODE, billing country will also change according to IP.

The master set up by Billing country:

```html
<span id="countryIsoCode" style="display: none;">$!CUSTOMER_COUNTRY_CODE</span>
<input name="customer_language_code" id="iso" type="hidden" value="$CUSTOMER_LANGUAGE"/>

```

### General API Usage

### Account balance

#### Introduction

Get balance APIs help Connecting Party to check current balances configured in Payment Gateway. Balances can be requested by Endpoint (for specific provider), by Merchant (specific balance or all balances) and by Manager (specific balance or all balances). Additionally, users with Manager account are able to upload balance adjustments by API.

#### Get Balance Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
A --> B: /api/v2/get-balance/
activate B
A <-- B: balance amount
deactivate B
```

(1) To implement get balance by Endpoint request see [/api/v2/get-balance/](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance.html.md).
 

#### Get Balance Merchant Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
A --> B: /api/v2/get-balance/merchant/
activate B
A <-- B: get balance by Merchant
deactivate B
```

(1) To implement get balance by Merchant request see [/api/v2/get-balance/merchant/](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_merchant.html.md).
 

#### Get Balance Manager Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
A --> B: /api/v2/get-balance/manager/
activate B
A <-- B: get balance by Manager
deactivate B
```

(1) To implement get balance by Manager request see [/api/v2/get-balance/manager/](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_manager.html.md).
 

#### Get Balance Adjustments Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
A --> B: /registry/upload/
activate B
A <-- B: Get Balance Adjustments
deactivate B
```

(1) To implement Get Balance Adjustments request see [Get Balance Adjustments](https://doc.payneteasy.com/integration/API_commands/accounts_adjustments.html.md).

### Glossary

| Payment Gateway | Payneteasy system that provides accepting, processing, storage and transmitting of payment data between members of payment process (Payer, Connecting Party, payment institutions). |
|--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Connecting Party | A third-party organization which implements integration to Payment Gateway following API Use-cases using API commands. |
| Merchant | User account in Payment Gateway provided to the merchant’s representatives. |
| Manager | User account in Payment Gateway provided to the representatives of PSP or payment institutions. |
| Reseller | User account in Payment Gateway provided to the agent, which engage merchants for PSP and payment institutions. |
| Payer | A person who pays for goods or services provided by Connecting Party. Also referred to as Customer. |
| Sender | A person who initiates the sending of funds from his side to another. |
| Receiver | A person who requests/receives funds from Sender or Connecting Party. |
| Acquirer | Member of payment system, which is licensed to accept payment cards. |
| Issuer | Member of payment system, which is licensed to issue payment cards. |
| Endpoint | Uniquely identified terminal in Payment Gateway, which is assigned to the Merchant and has to be provided in the commands within Payment Gateway API. |
| Endpoint Group | A set of endpoints with different currencies consolidated and available as one logical uniquely identified unit, which has to be provided in the commands within Payment Gateway API instead of endpoint. |
| Master Endpoint | Special endpoints that combine auxiliary endpoints. When making a payment, the Payer can choose the payment method he needs on the payment form. When choosing a payment method, auxiliary transactions on the corresponding endpoints are called on the side of the Payment Gateway, which leads to different payment methods being initiated. Relevant for Payment Cashier integration. See [Payment Cashier](https://doc.payneteasy.com/integration/api_use_cases/payment_cashier.html.md). |
| Auxiliary Endpoint | Regular endpoints united by master endpoint with their own settings and forms. Each auxiliary endpoint has its own payment method such as Credit card, Bank Transfer, Cryptocurrency, etc. Relevant for Payment Cashier integration. See [Payment Cashier](https://doc.payneteasy.com/integration/api_use_cases/payment_cashier.html.md). |
| Project | Payment Gateway entity which determines the conditions for receiving a payment message and its further routing to the connected Processor. |
| Gate | A set of parameters, which identify account registered in a third-party processing system. These parameters can be used to process payment data in an external system using the messaging protocol implemented in the Processor. |
| Processor | Payment Gateway internal entity, which encapsulates interconnection with third-party processing system (e.g. Acquirer). |
| PAN | Payment card number or Primary account number. |
| RPI | Recurring Payment Identification number. Identifier of tokenized cardholder data, gathered in initial transaction, or registered without a transaction, that can be used multiple times for recurring transactions. Some Payment Gateway APIs are designed to accept RPI, others are designed to accept Card reference ID. See respective Use-Case for details. |
| Card reference ID | Identifier of tokenized cardholder data, gathered in initial transaction that can be used multiple times for recurring transactions. Some Payment Gateway APIs are designed to accept RPI, others are designed to accept Card reference ID. See respective Use-Case for details. |
| Form | Form in which payment data is indicated. In Form APIs, the payment form is hosted on Payment Gateway side. In Direct APIs, the payment form is hosted on Connecting Party side. |
| ACS | 3DS Access Control Server. |
| 3DS Method | A scripting call provided by the 3DS Integrator that is placed on the 3DS Requestor website (the Connecting Party payment form or Payment Gateway payment form). Optionally used to obtain additional browser information to facilitate risk-based decisioning. |
| Pa Req | Payment authentication request message. See Pa Req in 3DS Decision Making Schema of the respective Use-Case. |
| Pa Res | Payment authentication response message. See Pa Res in 3DS Decision Making Schema of the respective Use-Case. |
| CReq | Challenge Request Message. See CReq in 3DS Decision Making Schema of the respective Use-Case. |
| CRes | Challenge Response Message. See CRes in 3DS Decision Making Schema of the respective Use-Case. |

### Google Pay™ App

#### Introduction

Google Pay™ is an electronic wallet system that allows making one-click payment using a card stored securely on Google side. There is no need to enter card details during Google Pay™ transaction.
 
Access to the payment mechanism is possible from any device, which supports Google Pay™.
 
After choosing Google Pay™ payment method, the payer will see the form on which he confirms his Google account and card he is going to use to pay for order. If payer doesn’t have a previously registered card, he may do it while making payment.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 

Integrate Google Pay™ in App with the following steps:

1. Read and accept [Terms of Service](#terms-of-serviceapp).
 
2. Follow [Google Pay™ Account Setup](#google-pay-account-setupapp).
 
3. Get the [Required Parameters for Google Pay™ Integration](#requiredgooglepayparameters).
 
4. Check the possible [Google Pay™ Authentication Types](#accsetupgooglepay), and [Google Pay™ Allowed Networks](#google-pay-allowed-networks).
 
5. Follow the transaction flow instructions. [Google Pay™ Sale Flow](#transactionflowappgoogle).
 

#### How to integrate Google Pay through Payneteasy

#### Terms of Service

The following rules must be complied to use Google Pay™:
 
The following rules must be complied to use Google Pay™ on mobile apps:
 

#### Google Pay™ Account Setup

1. Connecting Party must register in [Google Console](https://pay.google.com/business/console/). Instead of gmail, Connecting Party can use a corporate email address.

1. Then, from the account screen in the console, save the Merchant ID and proceed to the registration of the website in the Google Pay API section.

1. Add a website using the “Add website” button.

1. Specify screenshots of the checkout and payment form in the website settings, as well as integration type = Gateway and the address of the Connecting Party’s website from where the purchase starts.

1. Send the website address and Merchant ID to Payneteasy support managers.

#### Google Pay™ Integration in an Android App

Google Pay™ integration in an Android app supports only CRYPTOGRAM_3DS (tokenized) authentication type. All requests using PAN_ONLY (non-tokenized) authentication type will be automatically declined.

##### Google Pay™ Authentication Types

Connecting Party can independently choose the card types in Google Pay™ that will be available for payment. The card type is specified in the allowed Auth Methods Google request parameter.
 
There are two card types (authentication methods):
 
1. **PAN_ONLY** (non-tokenized) - cards stored in payer\`s Google account. These cards available on any device of the payer.
 
 The token contains the number and expiration date of the physical card. That is why 3-D Secure authentication is required for these cards. 3DS is required for PAN_ONLY cards. It can be indicated by the Success==3DS in Google payment response. 3-D Secure authentication does not differ from the standard 3-D Secure.
 
2. **CRYPTOGRAM_3DS** (tokenized) - cards that are stored tokenized on the payer’s device. Tokenized cards are only available on the device where the card was added to the Google Pay™ app.
 
 The token contains the number and expiration date of the virtual card as well as the 3-D Secure cryptogram. Customer 3-D Secure verification for tokenized cards is not required.
 

##### Google Pay™ Allowed Networks

Payment Gateway supports all networks specified in the allowed Card Networks Google request parameter, such as: VISA, MASTERCARD, etc. For the complete list of allowed networks refer to Payneteasy support.
 

##### Required Parameters for Google Pay™ Integration

1. [Register with Google](#google-pay-account-setupapp), accept [Google Terms of Service](#terms-of-serviceapp), and receive a Google merchant ID after website passes a Google review.
2. Request google Merchant GatewayID from Payneteasy support, which looks like: eXXX.mXXX.gate.payneteasy.eu, where:
 > eXXX - endpointID

 > mXXX - merchantID

 > An example of google Merchant GatewayID: e123.m567.gate.payneteasy.eu

3. Set gatewayID=google.gatewayid.
4. ENDPOINTID or ENDPOINTGROUPID received from Payneteasy support.
5. Control-key and Connecting Party login received from Payneteasy support.

##### Google Pay™ Sale Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
actor "Payer" as p
participant "Connecting Party\n mobile app" as m
participant "Payneteasy" as ppg
autonumber "(##)"
p -> m: checkout
activate m
== Retrieve Google Pay token data ==
m -> m: Check if Google Pay is available on the device
m --> p: Payment screen \ncontaining GooglePay button
activate p
p -> m: Press GooglePay button
deactivate p
m -> m: Create PaymentRequestData
m -> m: Call loadPaymentData\nPayneteasy, merchantGatewayId \nRetrieve Google Pay token
== Purchase Payment Request ==
m -> ppg: /mapi/v1/sale/ENDPOINTID\nencrypted-type=googlepay\nencrypted-data=hex(Google Pay token json)
activate ppg
ppg --> m: type=async-response, paynet-order-id=orderId
ppg -> ppg: Check signature and decrypt token data
alt authMethod=CRYPTOGRAM_3DS
ppg -> ppg : Process payment
else authMethod=PAN_ONLY
ppg-> ppg: stop processing\nset status=declined
end
== Status Request ==
m -> ppg: /api/v2/status/ENDPOINTID\n orderId=orderId
ppg--> m: Response\nstatus,order-stage
deactivate ppg
m--> p: Show payment result
deactivate m
```

(2)-(6) To implement retrieving of Google Pay token data within mobile application, please follow official tutorial from Google: [https://developers.google.com/pay/api/android/guides/tutorial](https://developers.google.com/pay/api/android/guides/tutorial).
 
(7) To implement Mobile API sale request, see /mapi/v1/sale/.
 
(12) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### Google Pay™ Web

#### Introduction

Google Pay™ is an electronic wallet system that allows you to make one-click payment using a card stored securely on Google side. There is no need to enter card details during Google Pay™ transaction.
 
Access to the payment mechanism is possible from any device, which supports Google Pay™.
 
After choosing Google Pay™ payment method, the payer will see the form on which he confirms his Google account and card he is going to use to pay for order. If payer doesn’t have a previously registered card, he may do it while making payment.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Integrate Google Pay™ in App with the following steps:
 
 
1. Read and accept [Terms of Service](#terms-of-serviceweb).
 
2. Follow [Google Pay™ Account Setup](#accsetupgooglepay-web).
 
3. Get the [Required Parameters for Google Pay™ Integration](#web-requiredgooglepayparameters).
 
4. Check the possible [Google Pay™ Authentication Types](#accsetupgooglepayweb), and [Google Pay™ Allowed Networks](#google-pay-allowed-networksweb).
 
5. Follow the transaction flow instructions: [Google Pay™ Web Flow](#transactionflowappgoogleweb).
 

#### How to integrate Google Pay through Payneteasy

#### Terms of Service

The following rules must be complied to use Google Pay™:
 
The following rules must be complied to use Google Pay™ on websites:
 

#### Google Pay™ Account Setup

1. Connecting Party must register in [Google Console](https://pay.google.com/business/console/). Instead of gmail, you can use a corporate email address.

1. Then, from the account screen in the console, save the Merchant ID and proceed to the registration of the website in the Google Pay API section.

1. Add a website using the “Add website” button.

1. Specify screenshots of the checkout and payment form in the website settings, as well as integration type = Gateway and the address of the Connecting Party’s website from where the purchase starts.

1. Send the website address and Merchant ID to Payneteasy support managers.

#### Google Pay™ Integration in a Connecting Party Website

##### Google Pay™ Authentication Types

Connecting Party can independently choose the card types in Google Pay™ that will be available for payment. The card type is specified in the allowed Auth Methods Google request parameter.
 
There are two card types (authentication methods):
 
1. **PAN_ONLY** (non-tokenized) - cards stored in payer\`s Google account. These cards available on any device of the payer.
 
 The token contains the number and expiration date of the physical card. That is why 3-D Secure authentication is required for these cards. 3DS is required for PAN_ONLY cards. It can be indicated by the Success==3DS in Google payment response. 3-D Secure authentication does not differ from the standard 3-D Secure.
 
2. **CRYPTOGRAM_3DS** (tokenized) - cards that are stored tokenized on the payer’s device. Tokenized cards are only available on the device where the card was added to the Google Pay™ app.
 
 The token contains the number and expiration date of the virtual card as well as the 3-D Secure cryptogram. Customer 3-D Secure verification for tokenized cards is not required.
 

##### Google Pay™ Allowed Networks

Payment Gateway supports all networks specified in the allowed Card Networks Google request parameter, such as: VISA, MASTERCARD, etc. For the complete list of allowed networks refer to Payneteasy support.
 

##### Required Parameters for Google Pay™ Integration

1. [Register with Google](#accsetupgooglepay-web), accept [Google Terms of Service](#terms-of-serviceweb), and receive a Google merchant ID after website passes a Google review.
2. ENDPOINT or ENDPOINGROUPID received from Payneteasy support.
3. Control-key and Connecting Party login received from Payneteasy support.

##### Google Pay™ Web Flow

```plantuml
autonumber
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
actor Payer as Customer
participant "Merchant\nwebsite" as Merchant
participant "Payneteasy" as g
participant "Google Pay™ service" as gps
Customer -> Merchant: checkout
activate Merchant
== Purchase payment request ==
Merchant -> g: sale-form/ENDPOINTID
activate g
Merchant -> g: **OR** preauth-form/ENDPOINTID
g --> Merchant: status=processing,\nredirect-url
deactivate g
Merchant -> Customer: redirect to payment-form redirect-url
deactivate Merchant
activate Customer
Customer -> g: GET redirect-url
deactivate Customer
activate g
g --> Customer: payment-form
deactivate g
activate Customer
Customer -> Customer: press Google Pay™ button
Customer -> Customer: choosing card
Customer -> gps: Submit Google Pay™ form
deactivate Customer
activate gps
gps -> Customer: cryptogram
deactivate gps
activate Customer
Customer -> g: submit payment data\ncryptogram
deactivate Customer
activate g
g -> g: decrypt\ncryptogram CHD
alt CRYPTOGRAM_3DS
g -> g: authorise payment\ntoken, expiry date, 3DS fields
else PAN_ONLY
g->g: retrieve\nIssuer ACS URL
g->Customer: redirect to Issuer ACS URL
activate Customer
Customer->Customer:pass 3DS authentication
Customer->g: redirect back\n3DS fields
deactivate Customer
g->g:authorise payment\nPAN, expiry date, 3DS fields
end
== Final redirect of customer ==
g -> Customer: Merchant website redirect-url
deactivate g
activate Customer
Customer -> Merchant: POST redirect-url\nstatus, orderid
deactivate Customer
activate Merchant
group Get Final Status
== Receive Connecting Party Callback ==
g -> Merchant: Callback with Final Status
activate g
Merchant --> g: HTTP 200
deactivate g
== Order status request ==
Merchant -> g: status/ENDPOINTID
activate g
g --> Merchant: response\nstatus, order-stage
deactivate g
end
Merchant --> Customer: Show result
deactivate Customer
deactivate Merchant
```

Below we can see Google Pay™ Purchase Flow and Integration steps:

(2) To implement sale-form payment request see [/api/v2/sale](https://doc.payneteasy.com/integration/API_commands/api_v2_sale.html.md).
 
(3) Instead of sale-form it is possible to implement preauth-form payment request see [/api/v2/preauth-form](https://doc.payneteasy.com/integration/API_commands/api_v2_preauth-form.html.md). Preauth allows to hold the specified amount in the Payer’s card account for a limited time. Preauth can be followed by [Capture](#capture-form-request-url-web) or [Cancel](#cancel-form-request-url-web).
 
(20) To implement Final Redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(22) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(24) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

##### Capture Flow

Capture is a transaction followed after preauth which deducts the locked amount from Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payneteasy" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Capture
  activate A
  end
  == Capture ==
  A -> B: api/v2/capture
  activate B
  B --> A: Order ID
  B -> B: Process Capture
  group Get Final Status
  == Receive Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Capture can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

##### Cancel Flow

Cancel is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payneteasy" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Cancel
  activate A
  end
  == Cancel ==
  A -> B: api/v2/cancel
  activate B
  B --> A: Order ID
  B -> B: Process Cancel
  group Get Final Status
  == Receive Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Cancel can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.

### Request Example for Insurance

```http
client_orderid=902B4FF5
&order_desc=Test Order Description
&first_name=John
&last_name=Smith
&ssn=1267
&birthday=19820115
&address1=100 Main st
&city=Seattle
&state=WA
&zip_code=98102
&country=US
&phone=+12063582043
&cell_phone=+19023384543
&amount=10.42
&insurance_amount=10
&email=john.smith@gmail.com
&currency=AED
&ipaddress=65.153.12.232
&site_url=www.google.com
&purpose=user_account1
&redirect_url=https://doc.payneteasy.com/doc/dummy.htm
&server_callback_url=https://httpstat.us/200
&merchant_data=VIP customer
&merchant_form_data=testparam%3Dtest1%26mynewparam%3Dtest2
&insured_person_first_name=John
&insured_person_last_name=Doe
&insured_person_middle_name=J
&insured_person_birthday=19820115
&insured_person_document_series=4111
&insured_person_document_number=562297
&insured_person_document_issue_date=19970117
&insured_person_document_issuer_name=First document department
&insured_person_registration_address=Seattle 100 Main st
&insured_person_phone=+12063582043
&insured_person_email=john.smith@gmail.com
&card_insurance_agreement_number=210H3FIM2426726391
&card_insurance_agreement_sell_date=20210115
&card_insurance_agreement_start_date=20210116
&card_insurance_agreement_end_date=20250115
&card_insurance_agreement_amount=20000
&card_insurance_agreement_bonus=4000
&control=c1ac1d532c96ddde35ad87be8b80a3d5aa0f2f48
```

### Payment Gateway Internal Errors

| Error id | Error message | Error type | Filter error code |
|------------|---------------------------------------------------------------------------|--------------|---------------------|
| 1 | MALFORMED_REQUEST | INTERNAL | |
| 2 | INVALID_CONTROL_CODE | INTERNAL | |
| 3 | MERCHANT_CONTROL_KEY_NOT_FOUND | INTERNAL | |
| 4 | ENDPOINT_ID_NOT_SPECIFIED | INTERNAL | |
| 5 | ERROR_PARSING_ENDPOINT_ID | INTERNAL | |
| 6 | ILLEGAL_STATE_FOR_RETURN | INTERNAL | |
| 7 | MERCHANT_NOT_FOUND | INTERNAL | |
| 8 | BAD_CREDIT_CARD_NUMBER | INTERNAL | |
| 9 | BAD_CREDIT_CARD_CVV | INTERNAL | |
| 10 | NO_CARD_PRINTED_NAME | INTERNAL | |
| 17 | LANGUAGE_NOT_FOUND_BY_CODE | INTERNAL | |
| 101 | ORDER_NOT_FOUND | INTERNAL | |
| 102 | INTERNAL_ERROR | INTERNAL | |
| 103 | CREATE_ORDER_ERROR | INTERNAL | |
| 104 | SESSION_VALIDATION_ERROR | INTERNAL | |
| 105 | CARD_NUMBER_ERROR | INTERNAL | |
| 106 | SESSION_STATUS_ERROR | INTERNAL | |
| 107 | WRONG_REVERSAL_AMOUNT | INTERNAL | |
| 108 | RETURN_AMOUNT_REQUIRES_CURRENCY | INTERNAL | |
| 109 | PARTIAL_REVERSAL_NOT_SUPPORTED | INTERNAL | |
| 111 | ALREADY_CAPTURED | INTERNAL | |
| 112 | CAPTURE_ALREADY_STARTED | INTERNAL | |
| 114 | WRONG_CAPTURE_AMOUNT | INTERNAL | |
| 115 | CAPTURE_AMOUNT_REQUIRES_CURRENCY | INTERNAL | |
| 116 | PARTIAL_CAPTURE_NOT_SUPPORTED | INTERNAL | |
| 117 | ACKNOWLEDGEMENT_CALL_NETWORK_ERROR | INTERNAL | |
| 118 | ACKNOWLEDGEMENT_CALL_ERROR | INTERNAL | |
| 119 | ACKNOWLEDGEMENT_INVALID_RESPONSE | INTERNAL | |
| 120 | ACKNOWLEDGEMENT_VALIDATION_ERROR | INTERNAL | |
| 121 | CARD_DATA_NOT_FOUND | INTERNAL | |
| 122 | CARD_DATA_RETRIEVAL_ERROR | INTERNAL | |
| 123 | INVALID_CALLBACK_URL | INTERNAL | |
| 501 | PAYMENT_FORM_CANCELED | INTERNAL | |
| 1001 | ERROR_CREATING_ORDER_INFO | INTERNAL | |
| 1002 | ERROR_CREATING_TRANSACTION | INTERNAL | |
| 1003 | CREATE_TRANSACTION_ERROR | INTERNAL | |
| 1004 | CREATE_SESSION_ERROR | INTERNAL | |
| 1005 | PROCESSING_EMPTY_GATES_LIST | INTERNAL | |
| 1006 | FILTERING_IS_FAILED | INTERNAL | |
| 1007 | CHECKING_IS_FAILED | INTERNAL | |
| 1008 | SECURE_3D_FAILED | INTERNAL | 1050 |
| 1009 | RANDOM_SUM_CHECK_FAILED | INTERNAL | 1051 |
| 1010 | PHONE_CHECK_FAILED | INTERNAL | 1057 |
| 1011 | RANDOM_SUM_CHECK_CANCELLED | INTERNAL | |
| 1012 | PHONE_CHECK_CANCELLED | INTERNAL | |
| 1013 | SYSTEM_UNAVAILABLE | INTERNAL | |
| 1014 | CARDNO_ENROLLED_CHECK_FAILED | INTERNAL | 1058 |
| 1015 | SECURE_3D_TIMEOUT | INTERNAL | |
| 1016 | MPI_STATUS_CHECK_FAILED | INTERNAL | 1059 |
| 1017 | ECI_STATUS_CHECK_FAILED | INTERNAL | 1060 |
| 1018 | CAVV_STATUS_CHECK_FAILED | INTERNAL | 1061 |
| 1019 | GATE_DESCRIPTOR_CHECK_CANCELLED | INTERNAL | |
| 1020 | GATE_DESCRIPTOR_CHECK_FAILED | INTERNAL | 1062 |
| 1021 | RAPIDA_BALANCE_CHECK_FAILED | INTERNAL | |
| 2001 | PROCESSOR_BAD_MESSAGE | INTERNAL | |
| 2002 | PROCESSOR_CONNECT_TIME_OUT | INTERNAL | |
| 2003 | PROCESSOR_GATE_IO_ERROR_ON_RESPONSE | INTERNAL | |
| 2004 | PROCESSOR_CAN_NOT_GET_EXTERNAL_ID | INTERNAL | |
| 2005 | PROCESSOR_OR_GATE_NOT_CONFIGURED_PROPERLY | INTERNAL | |
| 2006 | PROCESSOR_ERROR_ON_GATE | INTERNAL | |
| 2007 | PROCESSOR_NETWORK_PROBLEM | INTERNAL | |
| 2008 | PROCESSOR_INTERNAL_ERROR | INTERNAL | |
| 3001 | PROCESS_CALLBACK_UNKNOWN_RESULT_TYPE | INTERNAL | |
| 3002 | PROCESS_CALLBACK_NOT_VERIFIED | INTERNAL | |
| 10000 | Transaction was declined | INTERNAL | |
| N/A | project disabled | INTERNAL | |
| N/A | traffic disabled | INTERNAL | |
| N/A | end point disabled | INTERNAL | |
| N/A | merchant disabled | INTERNAL | |
| N/A | gate not found | INTERNAL | |
| N/A | zero weights | INTERNAL | |
| N/A | native rebill support check failed | INTERNAL | |
| N/A | Gate recurrent processor mismatch | INTERNAL | |
| N/A | Gate recurrent mid mismatch | INTERNAL | |
| 10002 | Credit card blacklisted | FILTER | 1022 |
| 10003 | End point limit is reached. Transaction can be processed only tomorrow. | FILTER | 1014 |
| 10004 | End point limit is reached. Transaction can be processed only next month. | FILTER | 1015 |
| 10010 | Client has bought this item already. | FILTER | 1018 |
| 10011 | Client (card) has bought this item already during period. | FILTER | 1020 |
| 10012 | Client (bin and e-mail) has bought this item already during period. | FILTER | 1021 |
| 10024 | To many card numbers from one IP and e-mail | FILTER | 1034 |
| 10025 | Customer e-mail, IP and holder filtered | FILTER | 1035 |
| 10027 | Issuer country in blacklist | FILTER | |
| 10028 | Country in blacklist | FILTER | |
| 10029 | Credit card issuer blacklisted | FILTER | 1039 |
| 10030 | IP address blacklisted | FILTER | 1040 |
| 10031 | Email blacklisted | FILTER | 1041 |
| 10033 | Email server blacklisted | FILTER | |
| 10046 | Disloyal customer | FILTER | |
| 10067 | Destination credit card blacklisted | FILTER | 1077 |
| 10068 | Email blacklisted | FILTER | 1078 |
| 10069 | Destination blacklisted | FILTER | 1079 |
| 10094 | Credit card blacklisted | FILTER | 1104 |
| 10095 | Destination credit card blacklisted | FILTER | 1105 |
| 10096 | IP address blacklisted | FILTER | 1106 |
| 10097 | Email blacklisted | FILTER | 1107 |
| 10098 | Destination blacklisted | FILTER | 1108 |
| 10106 | Merchant daily total limit reached | FILTER | 1116 |
| 10107 | Merchant monthly total limit reached | FILTER | 1117 |
| 10108 | Merchant daily 3D-Secure limit reached | FILTER | 1118 |
| 10109 | Merchant monthly 3D-Secure limit reached | FILTER | 1119 |
| 10110 | Merchant daily non 3D-Secure limit reached | FILTER | 1120 |
| 10111 | Merchant monthly non 3D-Secure limit reached | FILTER | 1121 |
| 10113 | Billing country in blacklist | FILTER | |
| 10116 | Merchant daily total limit for processor reached | FILTER | 1126 |
| 10117 | Merchant monthly total limit for processor reached | FILTER | 1127 |
| 10118 | Merchant daily 3D-Secure limit for processor reached | FILTER | 1128 |
| 10119 | Merchant monthly 3D-Secure limit for processor reached | FILTER | 1129 |
| 10120 | Merchant daily non 3D-Secure limit for processor reached | FILTER | 1130 |
| 10121 | Merchant monthly non 3D-Secure limit for processor reached | FILTER | 1131 |
| 10125 | Destination credit card issuer blacklisted | FILTER | 1135 |
| 10128 | Total filter score reached threshold (100) | FILTER | 1138 |
| 10130 | Merchant daily payout limit reached | FILTER | 1140 |
| 10131 | Merchant monthly payout limit reached | FILTER | 1141 |
| 10132 | Merchant daily payout limit for processor reached | FILTER | 1142 |
| 10133 | Merchant monthly payout limit for processor reached | FILTER | 1143 |
| 10134 | Limit reached | FILTER | 1144 |
| 10135 | PSP rules violation for no CVV transaction (CANCEL) | FILTER | 1145 |
| 10136 | PSP rules violation for no CVV transaction (PICKUP) | FILTER | 1146 |
| 10137 | Billing country blacklisted for merchant | FILTER | |
| 10138 | IP-address country blacklisted for merchant | FILTER | |
| 10139 | Customer e-mail blacklisted for merchant | FILTER | |
| 10140 | Customer fingerprint blacklisted for merchant | FILTER | |
| 10141 | Customer ip-address blacklisted for merchant | FILTER | |
| 10142 | Customer purpose blacklisted for merchant | FILTER | |
| 10143 | Destination card bin blacklisted for merchant | FILTER | |
| 10144 | Destination card country blacklisted for merchant | FILTER | |
| 10145 | Destination card number blacklisted for merchant | FILTER | |
| 10146 | Destination card type blacklisted for merchant | FILTER | |
| 10147 | E-mail domain blacklisted for merchant | FILTER | |
| 10148 | Source card bin blacklisted for merchant | FILTER | |
| 10149 | Source card country blacklisted for merchant | FILTER | |
| 10150 | Source card number blacklisted for merchant | FILTER | |
| 10151 | Source card type blacklisted for merchant | FILTER | |
| 10152 | Merchant loyal customer e-mail check failed | FILTER | |
| 10153 | Merchant loyal customer purpose check failed | FILTER | |
| 10154 | Merchant loyal destination card number check failed | FILTER | |
| 10155 | Merchant loyal source card number check failed | FILTER | |
| 10156 | Customer e-mail blacklisted for manager | FILTER | |
| 10157 | Customer fingerprint blacklisted for manager | FILTER | |
| 10158 | Customer ip-address blacklisted for manager | FILTER | |
| 10159 | Customer purpose blacklisted for manager | FILTER | |
| 10160 | Destination card number blacklisted for manager | FILTER | |
| 10161 | E-mail domain blacklisted for manager | FILTER | |
| 10162 | Source card number blacklisted for manager | FILTER | |
| 10163 | Manager loyal customer e-mail check failed | FILTER | |
| 10164 | Manager loyal customer purpose check failed | FILTER | |
| 10165 | Manager loyal destination card number check failed | FILTER | |
| 10166 | Manager loyal source card number check failed | FILTER | |
| 10168 | Merchant loyal customer e-mail + source card number end check failed | FILTER | |
| 10169 | Customer e-mail + source card number blacklisted for merchant | FILTER | |
| 10183 | Merchant loyal customer e-mail + source card number check failed | FILTER | |
| 10184 | Merchant loyal customer phone + source card number check failed | FILTER | |
| 10185 | Merchant loyal customer purpose + source card number check failed | FILTER | |
| 10186 | Merchant loyal customer fingerprint + source card number check failed | FILTER | |
| 10193 | Manager loyal customer e-mail + source card number check failed | FILTER | |
| 10194 | Source card mask blacklisted for merchant | FILTER | |
| 10195 | Destination card mask blacklisted for merchant | FILTER | |
| 10196 | Source card mask blacklisted for manager | FILTER | |
| 10197 | Destination card mask blacklisted for manager | FILTER | |
| 10260 | Manager loyal destination card mask check failed | FILTER | |
| 10261 | Merchant loyal source card mask check failed | FILTER | |
| 10262 | Merchant loyal destination card mask check failed | FILTER | |
| 10263 | Manager loyal source card mask check failed | FILTER | |
| 10271 | Customer phone number blacklisted for manager | FILTER | |
| 10272 | Customer phone number blacklisted for merchant | FILTER | |
| 15027 | Customer e-mail blacklisted for gate | FILTER | |
| 15028 | Customer fingerprint blacklisted for gate | FILTER | |
| 15029 | Customer ip-address blacklisted for gate | FILTER | |
| 15030 | Customer purpose blacklisted for gate | FILTER | |
| 15031 | Destination card number blacklisted for gate | FILTER | |
| 15032 | E-mail domain blacklisted for gate | FILTER | |
| 15033 | Source card number blacklisted for gate | FILTER | |
| 15010 | Gate loyal card number check failed | FILTER | |
| 15168 | Gate loyal destination card mask check failed | FILTER | |
| 15169 | Gate loyal destination card mask check failed | FILTER | |
| 15177 | Gate auto loyal customer email check failed | FILTER | |
| 15178 | Gate loyal source card mask and expiration date check failed | FILTER | |
| 15179 | Gate loyal source card mask and country billing check failed | FILTER | |
| 15180 | Gate loyal source card mask extended check failed | FILTER | |
| 15181 | Gate loyal destination card mask extended check failed | FILTER | |
| 18042 | Processor loyal source card number check failed | FILTER | |
| 18043 | Processor loyal destination card number check failed | FILTER | |
| 18110 | Processor loyal source card mask check failed | FILTER | |
| 18111 | Processor loyal destination card mask check failed | FILTER | |
| 15038 | Destination card bin blacklisted for processor | FILTER | |
| 15039 | Destination card country blacklisted for processor | FILTER | |
| 15040 | Source card bin blacklisted for processor | FILTER | |
| 15041 | Source card country blacklisted for processor | FILTER | |
| 10001 | Duplicate request | FILTER | 1007 |
| 10090 | Visa rules violation for preauthorized transaction (DELAY) | FILTER | 1100 |
| 15060 | Transaction amount is less than gate min allowed amount | FILTER | |
| 15019 | Transaction amount is greater than gate max allowed amount | FILTER | |
| 15062 | Billing country blacklisted for gate | FILTER | |
| 15063 | IP-address country blacklisted for gate | FILTER | |
| 15064 | Destination card country blacklisted for gate | FILTER | |
| N/A | end point balance reached | FILTER | |
| N/A | all mid limits have been reached | FILTER | |
| N/A | gate skipped in chain for card and error message | FILTER | |
| N/A | gate skipped in chain for card and error | FILTER | |
| N/A | Source card country blacklisted for processor | FILTER | |
| N/A | Reached processing limits capacity please contact your account manager | FILTER | |
| N/A | Reached balance limits capacity please contact your account manager | FILTER | |
| N/A | all gates were filtered out | FILTER | |

Besides the mentioned errors, handling of system filter codes and text messages should be implemented.
Full list of such filters can be found on transaction_filters

\* each acquirer has its own error codes list, ask your manager to provide you error codes of the exact acquirer that will be used in Live mode

### Joomla / Virtue Mart

The Payneteasy plugin for Joomla adds Payneteasy as a payment method to a
[Joomla](https://www.joomla.org/) store built on the [Virtue Mart](https://virtuemart.net/)
shopping cart component. Once installed and configured, customers can pay by card through
Payneteasy during Virtue Mart checkout.

A live demonstration shop with a Payneteasy Joomla plugin installed is available at
[joomla.codetime.net](https://joomla.codetime.net/).

> **Note:** This section describes the current plugin, [php-plugin-joomla-2](https://github.com/payneteasy/php-plugin-joomla-2), which targets Joomla + Virtue Mart and is distributed as a ready-to-install `payneteasy.zip` package. The earlier plugin for the Joom Shopping shopping cart is still available separately at [php-plugin-joomshopping](https://github.com/payneteasy/php-plugin-joomshopping); its installation (Composer build) and configuration differ from the steps below.

#### Source code

The plugin source is published on Git Hub at [payneteasy/php-plugin-joomla-2](https://github.com/payneteasy/php-plugin-joomla-2).

### Language Codes

#### Two-Letter Language Codes

| Country ID | Country | Code |
|--------------|--------------------------------|--------|
| 1 | Afar | aa |
| 2 | Abkhazian | ab |
| 3 | Afrikaans | af |
| 4 | Akan | ak |
| 5 | Albanian | sq |
| 6 | Amharic | am |
| 7 | Arabic | ar |
| 8 | Aragonese | an |
| 9 | Assamese | as |
| 10 | Avaric | av |
| 11 | Avestan | ae |
| 12 | Aymara | ay |
| 13 | Azerbaijani | az |
| 14 | Bashkir | ba |
| 15 | Bambara | bm |
| 16 | Basque | eu |
| 17 | Belarusian | be |
| 18 | Bengali | bn |
| 19 | Bihari languages | bh |
| 20 | Bislama | bi |
| 21 | Tibetan | bo |
| 22 | Bosnian | bs |
| 23 | Breton | br |
| 24 | Bulgarian | bg |
| 25 | Burmese | my |
| 26 | Catalan Valencian | ca |
| 27 | Czech | cs |
| 28 | Chamorro | ch |
| 29 | Chechen | ce |
| 30 | Church Slavic | cu |
| 31 | Chuvash | cv |
| 32 | Cornish | kw |
| 33 | Corsican | co |
| 34 | Cree | cr |
| 35 | Welsh | cy |
| 36 | Danish | da |
| 37 | German | de |
| 38 | Divehi Maldivian | dv |
| 39 | Dutch Flemish | nl |
| 40 | Dzongkha | dz |
| 41 | Greek, Modern | el |
| 42 | English | en |
| 43 | Esperanto | eo |
| 44 | Estonian | et |
| 45 | Ewe | ee |
| 46 | Faroese | eo |
| 47 | Persian | fa |
| 48 | Fijian | fj |
| 49 | Finnish | fi |
| 50 | French | fr |
| 51 | Western Frisian | fy |
| 52 | Fulah | ff |
| 53 | Georgian | ka |
| 54 | Gaelic Scottish Gaelic | gd |
| 55 | Irish | ga |
| 56 | Galician | gl |
| 57 | Manx | gv |
| 58 | Guarani | gn |
| 59 | Gujarati | gu |
| 60 | Haitian Haitian Creole | ht |
| 61 | Hausa | ha |
| 62 | Hebrew | he |
| 63 | Herero | hz |
| 64 | Hindi | hi |
| 65 | Hiri Motu | ho |
| 66 | Croatian | hr |
| 67 | Hungarian | hu |
| 68 | Armenian | hy |
| 69 | Igbo | ig |
| 70 | Icelandic | is |
| 71 | Ido | io |
| 72 | Sichuan Yi Nuosu | ii |
| 73 | Inuktitut | iu |
| 74 | Interlingue Occidental | ie |
| 75 | Interlingua | ia |
| 76 | Indonesian | id |
| 77 | Inupiaq | ik |
| 78 | Italian | it |
| 79 | Javanese | jv |
| 80 | Japanese | ja |
| 81 | Kalaallisut Greenlandic | kl |
| 82 | Kannada | kn |
| 83 | Kashmiri | ks |
| 84 | Kanuri | kr |
| 85 | Kazakh | kk |
| 86 | Central Khmer | km |
| 87 | Kikuyu Gikuyu | ki |
| 88 | Kinyarwanda | rw |
| 89 | Kirghiz Kyrgyz | ky |
| 90 | Komi | kv |
| 91 | Kongo | kg |
| 92 | Korean | ko |
| 93 | Kuanyama Kwanyama | kj |
| 94 | Kurdish | ku |
| 95 | Lao | lo |
| 96 | Latin | la |
| 97 | Latvian | lv |
| 98 | Limburgan Limburger Limburgish | li |
| 99 | Lingala | ln |
| 100 | Lithuanian | lt |
| 101 | Luxembourgish Letzeburgesch | lb |
| 102 | Luba-Katanga | lu |
| 103 | Ganda | lg |
| 104 | Marshallese | mh |
| 105 | Malayalam | ml |
| 106 | Marathi | mr |
| 107 | Macedonian | mk |
| 108 | Malagasy | mg |
| 109 | Maltese | mt |
| 110 | Mongolian | mn |
| 111 | Maori | mi |
| 112 | Malay | ms |
| 113 | Nauru | na |
| 114 | Navajo Navaho | nv |
| 115 | South Ndebele | nr |
| 116 | North Ndebele | nd |
| 117 | Ndonga | ng |
| 118 | Nepali | ne |
| 119 | Norwegian Nynorsk | nn |
| 120 | Bokmaal, Norwegian | nb |
| 121 | Norwegian | no |
| 122 | Chichewa Chewa Nyanja | ny |
| 123 | Occitan (post 1500) | oc |
| 124 | Ojibwa | oj |
| 125 | Oriya | or |
| 126 | Oromo | om |
| 127 | Ossetian Ossetic | os |
| 128 | Panjabi Punjabi | pa |
| 129 | Pali | pi |
| 130 | Polish | pl |
| 131 | Portuguese | pt |
| 132 | Pushto Pashto | ps |
| 133 | Quechua | qu |
| 134 | Romansh | rm |
| 135 | Romanian Moldavian Moldovan | ro |
| 136 | Rundi | rn |
| 137 | Russian | ru |
| 138 | Sango | sg |
| 139 | Sanskrit | sa |
| 140 | Sinhala Sinhalese | si |
| 141 | Slovak | sk |
| 142 | Slovenian | sl |
| 143 | Northern Sami | se |
| 144 | Samoan | sm |
| 145 | Shona | sn |
| 146 | Sindhi | sd |
| 147 | Somali | so |
| 148 | Sotho, Southern | st |
| 149 | Spanish Castilian | es |
| 150 | Sardinian | sc |
| 151 | Serbian | sr |
| 152 | Swati | ss |
| 153 | Sundanese | su |
| 154 | Swahili | sw |
| 155 | Swedish | sv |
| 156 | Tahitian | ty |
| 157 | Tamil | ta |
| 158 | Tatar | tt |
| 159 | Telugu | te |
| 160 | Tajik | tg |
| 161 | Tagalog | tl |
| 162 | Thai | th |
| 163 | Tigrinya | ti |
| 164 | Tonga (Tonga Islands) | to |
| 165 | Tswana | tn |
| 166 | Tsonga | ts |
| 167 | Turkmen | tk |
| 168 | Turkish | tr |
| 169 | Twi | tw |
| 170 | Uighur Uyghur | ug |
| 171 | Ukrainian | uk |
| 172 | Urdu | ur |
| 173 | Uzbek | uz |
| 174 | Venda | ve |
| 175 | Vietnamese | vi |
| 176 | Volapuk | vo |
| 177 | Walloon | wa |
| 178 | Wolof | wo |
| 179 | Xhosa | xh |
| 180 | Yiddish | yi |
| 181 | Yoruba | yo |
| 182 | Zhuang Chuang | za |
| 183 | Chinese | zh |
| 184 | Zulu | zu |

### Magento

The Paynet Easy Magento plugin lets a Magento-based store accept payments through Payneteasy without leaving the standard Magento checkout flow. Shoppers pick a product, go through the usual Magento checkout steps, and are handed off to the Paynet Easy payment form (or a direct/server-to-server flow, depending on configuration) to enter their card details.

A live example of the checkout flow is available on the [Magento demo shop](https://magento.codetime.net/).

> **Note:** The step-by-step configuration walkthrough in this page (menu paths, field-by-field descriptions, screenshots-style flow) is drawn from documentation written for the older Magento 1.x plugin (`payneteasy/php-plugin-magento`). The plugin actually linked from this documentation set, [php-plugin-magento-2](https://github.com/payneteasy/php-plugin-magento-2), targets Magento 2 and has a different internal structure (it ships as a standard `app/code/Paynet/Paynet Easy` module rather than the legacy Magento 1 module layout). The general concepts below (requirements, credentials to fill in, sandbox testing) still apply, but exact admin menu wording and installation commands may differ. Always check the plugin repository’s own README for Magento-2-specific instructions before installing.

#### Source code

The Magento 2 plugin source is published at [php-plugin-magento-2](https://github.com/payneteasy/php-plugin-magento-2). A working checkout built on this plugin can be tried on the [Magento demo shop](https://magento.codetime.net/).

### Connecting Party Callbacks

#### General information

If Connecting Party specified a callback URL, Payment Gateway sends an HTTP GET message to the callback URL whenever transaction reaches final status, no matter if the result is approved, declined or other [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md). This gives Connecting Party better control of how the transaction is processed, for example to add appropriate records to Connecting Party internal accounting system.

> **Warning:** Connecting Party server needs to respond to this GET request with 200 OK status [RFC](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.1), or else Payment Gateway will continue to send the callback 30 times for 14 days applying the progressive timeline.

Please remember, callbacks are guaranteed to report Connecting Party about transaction status. Connecting Party on their side must provide a means of preventing receiving the same callback twice - in case of network or other technical problems.
It is recommended to check status, type, orderid and client_orderid to prevent duplication of transactions on Connecting Party side.

Callback URLs can be specified by Connecting Party in the following ways:

* By sending server_callback_url or notify_url in initial transaction request. If server_callback_url is sent, Connecting Party will receive a callback only for the initial transaction (ex. sale approved). If notify_url is sent instead, Connecting Party will receive a callback for the initial transaction (ex. sale approved) and for any new transaction types applied to the same transaction (ex. reversal, chargeback).
* By specifying the callback URL on endpoint level. Each transaction type can have it’s own callback URL.

Only the following ports are allowed in callback URL:

* for HTTP 80, 8080
* for HTTPS 443, 8443

#### Customizable Callback URL

Simple callback URL contains all parameters listed in [Callback Parameters](#merchant-callback-parameters).
 
Customizable callback URL is a fully defined URL with all the parameters Connecting Party target page or script would require. Customizable URL allows Connecting Party to define own parameter names, whereas the actual parameters values are defined by use of macros with the following format ${parameter_name}. Thus gate.payneteasy.eu substitutes respective parameter values into final customized URL before calling it. Available macros are listed in [Callback Macros](#callback-macros).
 

Example of simple callback URL:

https://connectingparty.com/sale_completed.php

Example of customized callback URL:

https://connectingparty.com/sale_completed.php?cardholder_name=${name}&tx_status=${status}&order_id=${merchant_order}

#### Callback Parameters

> **Note:** The system automatically adds the following parameters to callback URL.

\* - these parameters are not defined by default. Please contact tech support to include these fields in callback.
 

| Callback Parameter | Description |
|-------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| merchant_order | Connecting Party order identifier, same as client_orderid. |
| client_orderid | Connecting Party order identifier. |
| orderid | gate.payneteasy.eu transaction id. |
| type | Transaction type, sale reversal chargeback |
| amount | Actual transaction amount. This value can be changed during the transaction flow. |
| currency | Transaction currency. |
| descriptor | Payment descriptor of the gate through which the transaction has been processed. |
| error_code | Error Code. This field won’t be included in callback in case transaction status=approved. |
| error_message | Error Message. This field won’t be included in callback in case transaction status=approved. |
| name | Cardholder Name. |
| email | Payer’s email. |
| country \* | Payer’s country (two-letter country code). Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid country codes. |
| state \* | Payer’s state . Please see [Country and State Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for a list of valid state codes. Mandatory for USA, Canada and Australia. |
| city \* | Payer’s city. |
| zip_code \* | Payer’s ZIP code. |
| address1 \* | Payer’s address line 1. |
| approval-code | Authorization approval code, if any. |
| last-four-digits | Last four digits of Payer’s credit card number. |
| bin | Bank BIN of Payer’s credit card. |
| card-type | Type of Payer’s credit card (VISA, MASTERCARD, etc). |
| phone | Payer’s phone number. |
| bank-name | Payer’s bank name. |
| card-exp-month | Card expiration month. |
| card-exp-year | Card expiration year. |
| gate-partial-reversal | Processing gate support partial reversal (enabled or disabled). |
| gate-partial-capture | Processing gate support partial capture (enabled or disabled). |
| reason-code | Reason code for chargeback or fraud operation. |
| processor-rrn | Bank Retrieval Reference Number. |
| comment | Comment in case of Return transaction |
| rapida-balance | Current balance for Connecting Party registered in Rapida system (only if balance check active) |
| control | Checksum is used to ensure that it is gate.payneteasy.eu (and not a fraudster) that initiates the callback to Connecting Party. This is SHA-1 checksum of the concatenation status + orderid + merchant_order + merchant_control. The callback script MUST check this parameter by comparing it to SHA-1 checksum of the above concatenation. |
| merchantdata | The value passed by Connecting Party in initial request. |
| serial-number | Serial number of the request. |
| processor-tx-id | Transaction id set by processor. |
| processor-auth-credit-code | Reserved |
| card-hash-id | Unique hash of the particular card, does not change. |
| verified-3d-status | Will return AUTHENTICATED if a transaction was approved by 3DS. |
| processor-credit-rrn | Retrieval Reference Number set by acquirer. |
| processor-credit-arn | Acquirer card reference number for credit card. |
| processor-debit-arn | Acquirer card reference number for debit card. |
| eci | Electronic Commerce Indicator (Visa). |
| ips-src-payment-product-code | Code for card set by multinational financial service. (Visa/Mastercard). |
| ips-src-payment-product-name | Decrypted code for card set by multinational financial service. (Visa/Mastercard). |
| ips-src-payment-type-code | Type of card code set by multinational financial service. (Visa/Mastercard). |
| ips-src-payment-type-name | Decrypted code for type of card set by multinational financial service. (Visa/Mastercard). |
| card-country-alpha-three-code | Three letter country code of source card issuer. See [Card Country Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| destination-card-country-alpha-three-code | Three letter country code of destination card issuer. See [Card Country Codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md) for details. |
| initial-amount | Amount, set in initiating transaction, without any fees or commissions. This value can’t change during the transaction flow. |
| customer-ip \* | The IP address of the customer |
| seller-commission \* | Total commission for processed transaction. |
| acquirer-commission \* | Acquirer commission for processed transaction. |
| exchange-rate \* | Basic exchange rate for currency conversion. |
| effective-exchange-rate \* | Actual exchange rate, applied during currency conversion. |
| motivational-message \* | This is an optional message which contains extended information about the reason for the declined transaction. |
| orig-amount | Contains the original request amount if it was converted on auxiliary endpoint in Parallel form integration. |
| orig-currency | Contains the original request currency if it was converted on auxiliary endpoint in Parallel form integration. |
| transaction-date | Callback receiving date and time. |

#### Callback Macros

| gate.payneteasy.eu Callback Macros name | Description |
|-------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ${status} | Transaction status, ex. approved, declined, processing, etc. |
| ${merchant_order} | Connecting Party order identifier, same as client_orderid. |
| ${orderid} | gate.payneteasy.eu transaction id. |
| ${type} | Transaction type, ex. sale, return, chargeback, etc. |
| ${amount} | Transaction amount. |
| ${descriptor} | Payment descriptor of the gate through which the transaction has been processed. |
| ${error_message} | Error message: when ${status} is declined. |
| ${name} | Cardholder Name. |
| ${email} | Payer’s email. |
| ${last-four-digits} | Last four digits of Payer’s credit card number. |
| ${bin} | Bank BIN of Payer’s credit card. |
| ${card-type} | Type of Payer’s credit card (VISA, MASTERCARD, etc). |
| ${card-exp-month} | Card expiration month. |
| ${card-exp-year} | Card expiration year. |
| ${gate-partial-reversal} | Processing gate support partial reversal (enabled or disabled). |
| ${gate-partial-capture} | Processing gate support partial capture (enabled or disabled). |
| ${reason-code} | Reason code for chargeback or fraud operation. |
| ${processor-rrn} | Bank Retrieval Reference Number. |
| ${approval-code} | Bank approval code. |
| ${comment} | Comment in case of Return transaction. |
| ${rapida-balance} | Current balance for Connecting Party registered in Rapida system (only if balance check active). |
| ${control} | Checksum is used to ensure that it is gate.payneteasy.eu (and not a fraudster) that initiates the callback to Connecting Party. This is SHA-1 checksum of the concatenation status + orderid + merchant_order + merchant_control. The callback script MUST check this parameter by comparing it to SHA-1 checksum of the above concatenation. |
| ${merchantdata} | The value passed by Connecting Party in initial request. |

#### Callback Request Example

```http
https://connectingparty.com/api/integration/check/pay/server?token=some_token
&serial-number=b8e5b762-c116-407e-a591-82a458e1
&merchant_order=preauth_1171
&client_orderid=preauth_1171
&processor-tx-id=e0a0572f-2154-737c-8ea7-92410
&orderid=57792
&status=approved
&amount=1.50
&currency=EUR
&descriptor=%D0%90+%D0%94%D0%B5%D0%BD%%D0%B3%D0%B8+-+card+registration
&original-gate-descriptor=%D0%90+%D0%940%BD%D1%8C%D0%B3%D0%B8+-+card+registration&gate-partial-capture=enabled
&type=preauth
&name=CARDHOLDER+NAME
&card-exp-month=6
&card-exp-year=2024
&email=22701231%40example.com
&processor-rrn=21660934567
&approval-code=265470
&control=bbd11a020f6bsdkfgjh23e24def54991bfb63c5&last-four-digits=0214
&bin=220220&card-type=VISA
&phone=%2B71914454778
&bank-name=Rabobank
&card-hash-id=235479750
&card-country-alpha-three-code=RUS
&ips-src-payment-product-code=VISA
&ips-src-payment-product-name=VISA
&ips-src-payment-type-code=Unknown
&ips-src-payment-type-name=VISA+Unknown
&initial-amount=1.50
&transaction-date=2022-06-15+12%3A37%3A02+CEST
```

#### Callback to Status Parameters Mapping

| Callback parameter Name | Status parameter Name |
|-------------------------------------------|-------------------------------------------|
| amount | amount |
| approval-code | approval-code |
| bin | bin |
| card-type | card-type |
| last-four-digits | last-four-digits |
| bank-name | bank-name |
| name | name |
| first-name | first-name |
| last-name | last-name |
| country | country |
| state | state |
| city | city |
| zip_code | zip_code |
| address1 | address1 |
| card-exp-month | card-exp-month |
| card-exp-year | card-exp-year |
| client_orderid | merchant-order-id |
| comment | comment |
| descriptor | descriptor |
| dest-bin | dest-bin |
| dest-card-type | dest-card-type |
| dest-last-four-digits | dest-last-four-digits |
| dest-bank-name | dest-bank-name |
| email | email |
| purpose | purpose |
| error_code | error-code |
| error_message | error-message |
| gate-partial-capture | gate-partial-capture |
| gate-partial-reversal | gate-partial-reversal |
| loyalty-balance | loyalty-balance |
| loyalty-bonus | loyalty-bonus |
| loyalty-message | loyalty-message |
| loyalty-program | loyalty-program |
| merchant_order | merchant-order-id |
| merchantdata | merchantdata |
| orderid | paynet-order-id |
| original-gate-descriptor | original-gate-descriptor |
| phone | phone |
| processor-rrn | processor-rrn |
| processor-tx-id | processor-tx-id |
| rapida-balance | rapida-balance |
| reason-code | reason-code |
| serial-number | serial-number |
| status | status |
| type | transaction-type |
| initial-amount | initial-amount |
| seller-commission | seller-commission |
| acquirer-commission | acquirer-commission |
| exchange-rate | exchange-rate |
| effective-exchange-rate | effective-exchange-rate |
| card-country-alpha-three-code | card-country-alpha-three-code |
| destination-card-country-alpha-three-code | destination-card-country-alpha-three-code |

#### Callback Signature Check Example on Java

You may see an example how to check the callback signature using JAVA programming language below:

```java
import org.junit.Test;

import java.nio.charset.StandardCharsets;
import java.security.MessageDigest;
import java.security.NoSuchAlgorithmException;

import static org.junit.Assert.assertEquals;

public class TestCallbackSignatureExampleTest {

    @Test
    public void test() {
        String digest3 = calculateCallbackSignature("approved", 123, "invoice-1", "AF4B5DE6-3468-424C-A922-C1DAD7CB4509");
        assertEquals("5bc8ee48f9ba37c0fd1e0b052a9bc105c6df87e1", digest3);
    }

    public String calculateCallbackSignature(String aTransactionStatus, long aOrderId, String aMerchantOrderId, String aMerchantControlKey) {
        String text   = aTransactionStatus + aOrderId + aMerchantOrderId + aMerchantControlKey;
        byte[] buffer = text.getBytes(StandardCharsets.UTF_8);
        byte[] shaSum = sha(buffer);
        return toHexString(shaSum);
    }

    /**
    * Calculates the SHA-1 digest and returns the value as a <code>byte[]</code>.
    *
    * @param data
    *            Data to digest
    * @return SHA-1 digest
    */
    private static byte[] sha(byte[] data) {
        try {
            MessageDigest digest = MessageDigest.getInstance("SHA");
            return digest.digest(data);
        } catch (NoSuchAlgorithmException e) {
           throw new IllegalStateException("Couldn't calculate SHA-1 digest", e);
        }
    }

    /**
     * Converts bytes to hex string
     */
    private static String toHexString(byte[] data) {
        StringBuilder sb = new StringBuilder();
        for (byte b : data) {
            String hex = Integer.toHexString(0xff & b);
            if (hex.length() == 1) {
                sb.append('0');
            }
            sb.append(hex);
        }
        return sb.toString();
    }

}
```

### Mobile Device Сard Verification

#### Introduction

Mobile Device Сard Verification allows Consumer to make transfer and sale transactions easier with a single verification process. During the process, the card is being validated by Payneteasy, mapped to reference on Connecting Party’s server. It allows Consumer to avoid entering card data for each transfer or sale transaction. Integration is based on HTTP POST requests/responses with JSON data.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Mobile Device Сard Verification Flow

```plantuml
@startuml
autonumber
title Mobile Device - 3-D Secure card verification
skinparam ParticipantPadding 70
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Payneteasy" as company
client <-> mobile: Authentication
mobile -> party: Request access token
mobile <-- party: Response access token
note right
accessToken
end note
mobile -> party: Initiate verification request
mobile <-- party: Initiate verification response
mobile -> company: Perform validation request
mobile <-- company: Perform validation response
note right
session token
end note
party <- company : Check verification request
party --> company : Check verification response
company -> company: Start processing
mobile -> company: Verification status request
note left
session token
end note
mobile <-- company: Verification status response
note right
state = PROCESSING
end note
mobile -> mobile: Open browser and provide \nredirectUrl to redirect to 3DS page
activate mobile
client <- mobile: Provide redirectUrl
client -> mobile: The cardholder provides auth data
mobile -> company: 3DS status update
company --> mobile: Close browser request
destroy mobile
company -> company: Process verification
party <- company: Verification card mapping notification request
note right
server card id
end note
party --> company: Verification card mapping notification response
mobile -> company: Verification status request
note left
session token
end note
mobile <-- company: Verification status response
note right
state = APPROVED|DECLINED
end note
party <- company: Callback with final status request
party --> company: Callback with final status response
@enduml
```

(1,2,3) To perform authentication of Consumer in Connecting Party’s app, Connecting Party can use any method which fits best to his needs. As a result, Connecting Party’s server generates {access Token} and provides it to Connecting Party’s app. This parameter will be used to start and continue session.
 
(4,5) To initiate card verification, Connecting Party’s app sends {access Token} with other device parameters to Connecting Party’s server. To implement initiate verification request see [Initiate verification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_verification.html.md).
 
(6,7) Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to check the card for being valid. To implement perform validation request see [Perform validation](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_validation.html.md).
 
(8,9) Check verification is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check verification request see [Check verification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_verification.html.md).
 
(11,12,21,22) Verification status request is made by Connecting Party’s app to Payneteasy to get the status of verification transaction. To implement verification status request see [Verification status](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_verification_status.html.md).
 
(19,20) Payneteasy sends Verification card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}. To implement verification card mapping notification request see [Verification card mapping notification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_verification_card_mapping_notification.html.md).
 
(23,24) If Connecting Party callback URL is specified on endpoint level, Payment Gateway sends message to this callback URL whenever transaction reaches final status, no matter if the result is approved, declined or has other [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md). See more in [Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).

### Mobile Device Sale

#### Introduction

Mobile device sale transaction can be performed with cardholder data or with card reference, previously made with [card verification](https://doc.payneteasy.com/integration/mobile_device_card_verification.html.md) process or in previous transfer/sale transactions.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Sale Flow

```plantuml
@startuml
autonumber
title Mobile Device - 3-D Secure sale
skinparam ParticipantPadding 70
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Payneteasy" as company
client <-> mobile: Authentication
mobile -> party: Request access token
mobile <-- party: Response access token
note right
accessToken
end note
party <- mobile: Initiate sale request
party --> mobile: Initiate sale response
mobile -> company: Perform sale request
mobile <-- company: Perform sale response
note right
session token
end note
company -> party: Check sale request
company <-- party: Check sale response
company -> company: Start processing
mobile -> company: Sale status request
note left
session token
end note
mobile <-- company: Sale status response
note right
state = REDIRECT_REQUEST
redirectUrl
end note
mobile -> mobile: Open browser and provide \nredirectUrl to redirect to 3DS page
activate mobile
client <-- mobile: Provide redirectUrl
client -> mobile: The cardholder provides auth data
mobile -> company: 3DS status update
company --> mobile: Close browser request
destroy mobile
company -> company: Process sale
    party <- company: Sale card mapping notification request
note right
server card id
end note
party --> company: Sale card mapping notification response
mobile -> company: Sale status request
note left
session token
end note
mobile <-- company: Sale status response
note right
bankorder id
state = APPROVED|DECLINED
end note
party <- company: Callback with final status request
party --> company: Callback with final status response
@enduml
```

(1,2,3) To perform authentication of Consumer in Connecting Party’s app, Connecting Party can use any method which fits best to his needs. As a result, Connecting Party’s server generates {access Token} and provides it to Connecting Party’s app. This parameter will be used to start and continue session.
 
(4,5) To initiate sale, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}. To implement initiate sale request see [Initiate Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_sale.html.md).
 
(6,7) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform sale transaction. To implement perform sale request see [Perform sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_sale.html.md).
 
(8,9) Check sale is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check sale request see [Check Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_sale.html.md).
 
(11,12,21,22) Sale status request is made by Connecting Party’s app to Payneteasy to get the status of sale transaction. To implement sale status request see [Sale status](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_sale_status.html.md).
 
(19,20) Payneteasy sends Sale card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}. To implement sale card mapping notification request see [Sale card mapping notification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_sale_card_mapping_notification.html.md).
 
(23,24) If Connecting Party callback URL is specified on endpoint level, Payment Gateway sends message to this callback URL whenever transaction reaches final status, no matter if the result is approved, declined or has other [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md). See more in [Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 

#### Repeat Sale Flow

After successful Card mapping procedure, new sale transactions with the same cardholder data can be done easier for Consumer.
 
Connecting Party’s app makes new sale requests using {client Card Id} instead of cardholder data. Payneteasy sends this {client Card Id} to Connecting Party’s server in “Check sale request” and gets mapped to it {server Card Id} in “Check sale response” from Connecting Party’s server. This {server Card Id} is used to continue the processing of sale transaction.
 
Transaction flow remains the same: [Initiate Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_sale.html.md) -> [Perform sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_sale.html.md) -> [Check Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_sale.html.md).
 
If there is no need to change Consumer’s data (such as address, phone, etc.), “Perform sale request” for Repeat sale may be sent without any optional parameters. If Consumer’s data has to be changed, new source card reference must be created.
 
If {client Card Id} is used in “Perform sale request”, {server Card Id} must be included in “Check sale response” and signature.
 
If {client Card Id} was mapped to {server Card Id} in transaction with included {consumer.email} value, new “Perform sale request” and “Check sale response” with this {client Card Id} must also contain the same {consumer.email} value.
 
 
For Repeat Sale Flow use the following parameters in Perform Sale request:
 
 
1. {source Of Funds.reference.client Card Id}
2. {source Of Funds.reference.security Code}

Instead of:
 
 
1. {source Of Funds.card.expiry.month}
2. {source Of Funds.card.expiry.year}
3. {source Of Funds.card.holder}
4. {source Of Funds.card.holder.first Name}
5. {source Of Funds.card.holder.last Name}
6. {source Of Funds.card.number}
7. {source Of Funds.card.security Code}

```plantuml
@startuml
autonumber
title Mobile Device - Card references for Repeat sale
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Payment Gateway" as company
skinparam ParticipantPadding 80
== Last part of previous transaction ==
party <- company: Card mapping notification request
note right
serverCardId
end note
party --> company: Card mapping notification response
party --> party: Create clientCardId for serverCardId
party -> mobile: Store reference in app or send it by request
note right
clientCardId
end note
== New sale ==
mobile -> party: Initiate sale request
mobile <-- party: Initiate sale response
mobile -> company: Perform sale request
note left
clientCardId
end note
mobile <-- company: Perform sale response
party <- company: Check sale request
note right
clientCardId
end note
party --> company: Check sale response
note left
serverCardId
end note
company -> company: Process sale
@enduml
```

(1,2) Payneteasy sends Sale card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}. To implement sale card mapping notification request see [Sale card mapping notification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_sale_card_mapping_notification.html.md).
 
(5,6) To initiate sale, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}. To implement initiate sale request see [Initiate Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_sale.html.md).
 
(7,8) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform sale transaction. To implement perform sale request see [Perform sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_sale.html.md).
 
(9,10) Check sale is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check sale request see [Check Sale](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_sale.html.md).

### Mobile Device Transfer

#### Introduction

Mobile device transfer can be performed with cardholder data of sender and receiver of funds or with card reference, previously made with [card verification](https://doc.payneteasy.com/integration/mobile_device_card_verification.html.md) process or in previous transfer/sale transactions.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Transfer Flow

```plantuml
@startuml
autonumber
title Mobile Device - 3-D Secure card funds transfer
skinparam ParticipantPadding 70
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Payneteasy" as company
client <-> mobile: Authentication
mobile -> party: Request access token
mobile <-- party: Response access token
note right
accessToken
end note
mobile -> party: Initiate transfer request
mobile <-- party: Initiate transfer response
mobile -> company: Perform transfer request
mobile <-- company: Perform transfer response
note right
session token
end note
party <- company : Check transfer request
party --> company : Check transfer response
company -> company: Start processing
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
state = REDIRECT_REQUEST
end note
mobile -> mobile: Open browser and provide \nredirectUrl to redirect to 3DS page
activate mobile
client <-- mobile: Provide redirectUrl
client -> mobile: The cardholder provides auth data
mobile -> company: Transfer status update
company --> mobile: Close browser request
destroy mobile
company -> company: Process transfer
    party <- company: Transfer card mapping notification request
note right
server card id
end note
    party --> company: Transfer card mapping notification response
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
bankorder id
state = APPROVED|DECLINED
end note
party <- company: Callback with final status request
party --> company: Callback with final status response
@enduml
```

(1,2,3) To perform authentication of Consumer in Connecting Party’s app, Connecting Party can use any method which fits best to their needs. As a result, Connecting Party’s server generates {access Token} and provides it to Connecting Party’s app. This parameter will be used to start and continue session.
 
(4,5) To initiate funds transfer, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}. To initiate transfer request see [Initiate Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_transfer.html.md).
 
(6,7) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform funds transfer from card to card. To implement perform transfer request see [Perform Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_transfer.html.md).
 
(8,9) Check transfer is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check transfer request see [Check Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_transfer.html.md).
 
(11,12,21,22) Funds transfer status request is made by Connecting Party’s app to Payneteasy to get the status of transfer transaction. To implement transfer status request see [Status Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_transfer_status.html.md).
 
(19,20) Payneteasy sends Transfer card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}. To implement transfer card mapping notification request see [Transfer card mapping notification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_transfer_card_mapping_notification.html.md).
 
(23,24) Connecting Party specified a callback URL, Payment Gateway sends message to the callback URL whenever transaction reaches final status, no matter if the result is approved, declined or other [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md). See more [Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 

#### Repeat Transfer Flow

After successful Card mapping procedure, new transfers with the same cardholder data can be done easier for Consumer.
 
Connecting Party’s app makes new transfer requests using {client Card Id} instead of source and/or destination cardholder data. Payneteasy sends these {client Card Id} to Connecting Party’s server in “Check transfer request” and gets mapped to it {server Card Id} in “Check transfer response” from Connecting Party’s server. These {server Card Id} are used to continue the processing of transfer transaction.
 
Transaction flow remains the same: [Initiate Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_transfer.html.md) -> [Perform Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_transfer.html.md) -> [Check Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_transfer.html.md).
 
If there is no need to change Consumer’s data (such as address, phone, etc.), “Perform transfer request” for Repeat transfer may be sent without any optional parameters and with card references for sender and receiver instead of cardholder data. If Consumer’s data has to be changed, new source card reference must be created.
 
If source and/or destination {client Card Id} are used in “Perform transfer request”, source and/or destination {server Card Id} must be included in “Transfer check response” and signature.
 
If source {client Card Id} was mapped to {server Card Id} in transaction with included {consumer.email} value, new “Perform transfer request” and “Check signature response” with this {client Card Id} must also contain the same {consumer.email} value.
 
 
For Repeat Transfer Flow use the following source of funds parameters in Perform Transfer request:
 
 
1. {source Of Funds.reference.client Card Id}
2. {source Of Funds.reference.security Code}

Instead of:
 
 
1. {source Of Funds.card.expiry.month}
2. {source Of Funds.card.expiry.year}
3. {source Of Funds.card.holder}
4. {source Of Funds.card.holder.first Name}
5. {source Of Funds.card.holder.last Name}
6. {source Of Funds.card.number}
7. {source Of Funds.card.security Code}

For destination of funds use {destination Of Funds.reference.client Card Id} instead of {destination Of Funds.card.number}.
 
```plantuml
@startuml
autonumber
title Mobile Device - Card references for Repeat transfer
participant "Mobile App" as mobile
participant "Connecting Party's Server" as party
participant "Payneteasy" as company
skinparam ParticipantPadding 80
== Last part of card verification or transfer ==
party <- company: Card mapping notification request
note right
serverCardId
end note
party --> company: Card mapping notification response
party --> party: Create clientCardId for serverCardId
party -> mobile: Store reference in app or send it by request
note right
clientCardId
end note
== New transfer ==
mobile -> party: Initiate transfer request
mobile <-- party: Initiate transfer response
mobile -> company: Perform transfer request
note left
clientCardId
end note
mobile <-- company: Perform transfer response
party <- company: Check transfer request
note right
clientCardId
end note
party --> company: Check transfer response
note left
serverCardId
end note
company -> company: Process transfer
@enduml
```

(1,2) Payneteasy sends Transfer card mapping notification request to Connecting Party’s server/proxy with created on its side card reference - {server Card Id}. To implement transfer card mapping notification request see [Transfer card mapping notification](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_transfer_card_mapping_notification.html.md).
 
(5,6) To initiate funds transfer, Connecting Party’s app sends {access Token} with transaction amount and other device parameters to Connecting Party’s server, which are used to start a session with unique random {nonce} and encrypted {signature}. To initiate transfer transfer request see [Initiate Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_initiate_transfer.html.md).
 
(7,8) On this stage Connecting Party’s app sends cardholder, device, session data and other parameters straight to Payneteasy to perform funds transfer from card to card. To implement perform transfer request see [Perform Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_perform_transfer.html.md).
 
(9,10) Check transfer is used for security purposes and allows Payneteasy to compare the data sent by Connecting Party’s app with the data stored on Connecting Party’s server. To implement check transfer request see [Check Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device_server/api_check_transfer.html.md).
 
 

#### Consumer Defined Transfer Rates Flow

Consumer defined transfer rates is an optional feature which allows the sender to choose the most suitable commission amount for his transfer transaction between several available payment provider gates.
 
The possibility of such feature depends on the integration. Please ask support manager for details.
 
When such feature is enabled, the Transfer Flow extends:
 
1. If Check transfer has been successful, Payneteasy pauses the processing, includes the list of possible commissions to next Transfer status response and awaits for confirmation from the Consumer.
2. Consumer selects the most suitable commission from the list in the Connecting Party’s app.
3. Connecting Party’s app sends the selected gate (using its assigned Id aliased name) in Complete transfer request to Payneteasy.
4. Payneteasy continues to process the transaction on the selected gate.

```plantuml
@startuml
autonumber
title Consumer defined transfer rates
participant "Consumer" as client
participant "Mobile App" as mobile
participant "Payneteasy" as company
== Transfer has been checked successfully ==
company -> company : Pause the transaction
loop until Complete transfer is sent
mobile -> company: Transfer status request
note left
session token
end note
mobile <-- company: Transfer status response
note right
state=TRANSFER_FEE_REQUEST
transferFeeList
end note
end
mobile -> client: Ask to select the commission
mobile <-- client: Commission selected
mobile -> company: Complete transfer request
    note left
    assignedId
    end note
mobile <-- company: Complete transfer response
company -> company: Continue processing
@enduml
```

(2,3) Funds transfer status request is made by Connecting Party’s app to Payneteasy to get the status of transfer transaction. To implement transfer status request see [Status Transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_transfer_status.html.md). Transfer status response includes the state parameter with TRANSFER_FEE_REQUEST value and the transfer Fee List object with a list of commissions for possible processing gates. Each processing gate is represented by it’s own aliased name in assigned Id parameter. TRANSFER_FEE_REQUEST value in state parameter exists only in “Consumer defined transfer rates” flow. The mentioned parameters may not be presented in first Transfer status response, so Connecting Party’s app should continue polling the transaction status. When the transaction reaches TRANSFER_FEE_REQUEST state, the processing will remain paused until Complete transfer request is sent.
 
(6,7) To implement Complete transfer request see [Complete transfer](https://doc.payneteasy.com/integration/API_commands/api_mobile_device/api_complete_transfer.html.md).

### MODX

The [php-plugin-modx](https://github.com/payneteasy/php-plugin-modx) repository
contains a payment module for [MODX Revolution](https://modx.com/) sites that
use the mini Shop2 e-commerce extension. It adds Payneteasy as a payment
method inside mini Shop2’s checkout so orders placed on a MODX/mini Shop2 storefront
can be paid through the Payneteasy gateway.

There is no public demo shop for this plugin; the steps below are based on the
plugin’s own installation and removal notes rather than a live installation.

#### Source code

The plugin’s source and the installation/removal notes it is based on are
published at [payneteasy/php-plugin-modx](https://github.com/payneteasy/php-plugin-modx).

### mPOS API

#### Introduction

mPOS is a device that is able to read card data from plastic cards (like magnetic stripe tracks) or other devices and transmit this data to the Payneteasy mPOS API in an encrypted form.
 
mPOS API (MAPI) supports [Sale](#mpos-api-sale) and [Preauth](#mpos-api-preauth) transactions with status requests and callbacks for transaction status handling.
 
Depending on the exact acquiring solution, it might be required to implement regular Close Day procedure for bank payment clearing via /api/v2/close-day/ API command. Please contact support manager for details.
 

#### Mobile App Integration flow

Payneteasy team creates a dedicated account on sandbox environment and provides integrator with test ENDPOINTID, merchant_control_key and test mPOS devices with pre-installed encryption key for processing test transactions.
mPOS devices (each has a serial number) are handed to integrator along with SDK for communication (see [mPOS SDK for iOS](https://doc.payneteasy.com/integration/mpos_sdk_for_ios.html.md) and [mPOS SDK for Android and Java](https://doc.payneteasy.com/integration/mpos_sdk_for_android_and_java.html.md)).
Integrator team implements Sale and/or Preauth transaction flows and Mobile App-to-mPOS communication tailoring their needs.

##### Sale Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /mapi/v1/sale/
activate B
B --> A: Order ID
B -> B: Process\nSale
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement sale request see /mapi/v1/sale/.
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

##### Preauth Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /mapi/v1/preauth/
activate B
B --> A: Order ID
B -> B: Process\nPreauth
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement preauth request see /mapi/v1/preauth/.
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### mPOS Integration

### mPOS API Ru

#### Закрытие дня

**Описание закрытия дня**

Деньги переводятся на расчетный счет торговца после закрытия дня. При неуспешном завершении процедуры закрытия дня или если процедура закрытия вовсе не инициируется торговцем, операция клиринга не производится, таким образом деньги не зачисляются на расчетный счет торговца.

Если по какой-либо причине не удается провести закрытие дня, используя «Удаленное закрытие дня», необходимо провести операцию закрытия дня вручную через личный кабинет или обратиться за помощью в службу поддержки.

Данная операция доступна не для всех эквайеров, за информацией обращайтесь в службу поддержки.

Для закрытия дня доступны следующие способы:

[Принудительное закрытие дня](#manuallycloseday)

[Автоматическое закрытие дня](#autocloseday)

[Автоматическое закрытие дня по заранее установленному времени](#autoclosedaytime)

[Удаленное закрытие дня](#apicloseday)

##### Принудительное закрытие дня

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

> `pic1 close_day`
 
> `pic2 close_day`

На странице шлюза нажмите кнопку “Закрыть день” и подтвердите закрытие дня на всплывающем окне. На странице начнет отображаться окно “Закрытие дня для ‘имя шлюза’”, дождитесь завершения операции.

> `pic3 close_day`

После успешного закрытия дня на странице шлюза будет отображена информация о дате закрытия и сумме транзакций с момента последнего закрытия дня для данного шлюза до текущего закрытия дня.

> `pic4 close_day`

> **Warning:** Во время закрытия дня шлюз блокируется и транзакции по нему проходить не будут.

##### Автоматическое закрытие дня

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

> `pic1 close_day`
 
> `pic2 close_day`

На странице шлюза нажмите кнопку “Редактировать”, поставьте галочку напротив пункта “Автоматическое закрытия дня” и нажмите “Сохранить”.

> `pic5 close_day`
При автоматическом закрытии дня оптимальное время закрытия выбирается системой автоматически (ближе к концу рабочего дня по МСК).
 

> **Warning:** Во время автоматического закрытия дня шлюз блокируется и транзакции по нему проходить не будут.

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

> `pic4 close_day`

##### Автоматическое закрытие дня по заранее установленному времени

Для автоматического закрытия дня по заданному времени менеджеру или его сотруднику в личном кабинете системы надо перейти в настройки шлюза, для которого требуется закрывать день автоматически в установленное время.
 
> `pic1 close_day`
 
> `pic2 close_day`
На странице шлюза нажмите кнопку “Редактировать”, поставьте галочку напротив пункта “Закрывать день автоматически”, появится пункт “Время закрытия дня”, нужно выставить время закрытия дня, затем нажать “Сохранить”.
 
Обратите внимание, что пункт “Автоматическое закрытия дня” должен быть выключен, иначе время закрытия дня будет выбрано автоматически системой.
 
> `pic6 close_day`

Закрытие дня будет выполняться в заданное время, после успешного закрытия дня на странице шлюза будет отображена информация о дате закрытия и сумме транзакций с момента последнего закрытия дня для данного шлюза до текущего закрытия дня.

> `pic6 close_day`

> **Warning:** Во время автоматического закрытия дня по заданному времени шлюз блокируется и транзакции по нему проходить не будут.

##### Удаленное закрытие дня

Удаленное закрытие дня позволяет закрыть день сразу на всех шлюзах определенного терминала. Для этого необходимо для ВСЕХ шлюзов ассоциированных с терминалом установить в настройках “Удаленное закрытие дня”.
 
Для удаленного закрытия дня менеджеру или его сотруднику в личном кабинете системы надо перейти в настройки шлюза, для которого требуется включить удаленное закрытие дня.
 
> `pic1 close_day`
 
> `pic2 close_day`
На странице шлюза нажмите кнопку “Редактировать”, поставьте галочку напротив пункта “Удаленное закрытие дня”, при необходимости, задайте число дней через которое будет срабатывать автоматическое закрытие дня, начиная с последнего успешного удаленного закрытия дня - пункт “Максимальная задержка закрытия дня (дн.)”, автоматически устанавливается 3 дня, затем нажмите “Сохранить”.
 
> `pic8 close_day`

> **Warning:** Во время удаленного закрытия дня шлюзы блокируются и транзакции по ним проходить не будут.

Для инициации Удаленного закрытия дня необходимо отправить HTTP запрос следующего вида:
 
```text
POST https://${hostname}/paynet/api/v2/close-day/{endpointId}
```

Аутентификация пользователя происходит по OAuth 1.0, описание: [oauth](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md)
 

**Тело запроса**

В теле запроса укажите данные со следующей структурой:
 
```text
{
  "day_close_request_id": {string},
  "sale_approved_count": {string},
  "sale_approved_sum": {string},
  "reversal_approved_count": {string},
  "reversal_approved_sum": {string}
}
```

**Обязательные параметры**

| Имя свойства | Тип(длина) | Описание |
|----------------------|--------------|-----------------------------------------------------------------|
| day_close_request_id | string(8-32) | Уникальный идентификатор запроса. Может содержать буквы и цифры |

**Необязательные параметры**

| Имя свойства | Тип(длина) | Описание |
|-------------------------|--------------|----------------------------------------------|
| sale_approved_count | string | Число подтвержденных sale транзакций |
| sale_approved_sum | string | Сумма по подтвержденным sale транзакциям |
| reversal_approved_count | string | Число подтвержденных reversal транзакций |
| reversal_approved_sum | string | Сумма по подтвержденным reversal транзакциям |

**Тело ответа**

Пользователь генерирует идентификатор запроса и посылает запрос на закрытие дня. Если этот идентификатор используется впервые - начинается инициализация закрытия дня для гейта(ов), ассоциированного(ых) с переданным идентификатором терминала. Пользователю возвращается асинхронный ответ со статусом ‘starting’.
 
Пример структуры ответа следующий:
 
```text
{
  "response": {
    "status": "starting",
    "gates": [ {
      "gateId": 193,
      "isDayClosing": true,
      "epntId": 1
      }, {
      "gateId": 82,
      "isDayClosing": true,
      "epntId": 1
      }, {
      "gateId": 317,
      "isDayClosing": true,
      "epntId": 1
    }
    ]
  },
  "theRequestSerialNumber": "00000000-0000-0000-0000-00000000001c"
}
```

| Имя свойства | Тип | Описание |
|------------------------|---------|-------------------------------------------------------------------------|
| status | string | Статус операции закрытия дня |
| gate Id | long | Идентификатор шлюза по которому происходит закрытие дня |
| is Day Closing | boolean | Флаг закрытия дня, при значении true - шлюз заблокирован |
| epnt Id | long | Свойство, присваемое банком терминалу при его настройке в системе банка |
| the Request Serial Number | string | Серийный номер запроса закрытия дня |
Запрос с идентификатором day_close_request_id, уже использованным ранее, выполняет функцию статус-запроса. После первичного (инициирующего запроса) пользователь может продолжать посылать запросы по тому же адресу с тем же самым идентификатором запроса. В данном случае, этот идентификатор всегда будет ассоциирован с процедурой закрытия дня, которую он инициировал. Пока операция по закрытию дня в процессе выполнения - пользователю будет возвращаться асинхронный ответ со статусом ‘processing’.
 
Пример структуры ответа следущий:
 
```text
{
  "response": {
    "status": "processing",
    "gates": [ {
      "gateId": 193,
      "isDayClosing": true,
      "epntId": 1
      }, {
      "gateId": 82,
      "isDayClosing": true,
      "epntId": 1
      }, {
      "gateId": 317,
      "isDayClosing": true,
      "epntId": 1
    }
    ]
  },
  "theRequestSerialNumber": "00000000-0000-0000-0000-00000000001e"
}
```

| Имя свойства | Тип | Описание |
|------------------------|---------|-------------------------------------------------------------------------|
| status | string | Статус операции закрытия дня |
| gate Id | long | Идентификатор шлюза по которому происходит закрытие дня |
| is Day Closing | boolean | Флаг закрытия дня, при значении true - шлюз заблокирован |
| epnt Id | long | Свойство, присваемое банком терминалу при его настройке в системе банка |
| the Request Serial Number | string | Серийный номер запроса закрытия дня |
Информация о закрытом дне появится в ответе от сервера по мере ее поступления от процессоров (в случае одновременного закрытия нескольких гейтов). После закрытия дня гейта(ов) статус ответа примет значение ‘finished’, вне зависимости от того, завершилось ли закрытие дня на всех гейтах успешно, или часть гейтов (или все) закрылись с ошибкой.
 

> **Warning:** Если во время удаленного закрытия дня шлюз(ы) останутся в заблокированном состоянии (в теле ответа при “status”: “finished” для шлюза - “is Day Closing”: true), воспользуйтесь инструментом снятия блокировки в личном кабинете системы, который описан далее в этом разделе.

Пример структуры ответа следующий:
 
```text
{
  "response": {
    "status": "finished",
        "gates": [ {
              "gateId": 193,
              "isDayClosing": false,
              "gateCloseDate": "Mon Dec 10 14:44:21 MSK 2018",
              "epntId": 1,
              "saleApprovedCount": "2334",
              "saleAmount": "87328428482.00",
              "reversalApprovedCount": "123",
              "reversalAmount": "12393423.00",
              "code39": "000",
              "RRN": "2034829434"
              }, {
              "gateId": 82,
              "isDayClosing": false,
              "gateCloseDate": "Mon Dec 10 14:44:21 MSK 2018",
              "epntId": 1,
              "saleApprovedCount": "2334",
              "saleAmount": "87328428482.00",
              "reversalApprovedCount": "123",
              "reversalAmount": "12393423.00",
              "code39": "000",
              "RRN": "2034829434"
              }, {
              "gateId": 317,
              "isDayClosing": false,
              "gateCloseDate": "Mon Dec 10 14:44:21 MSK 2018",
              "epntId": 1,
              "saleApprovedCount": "2334",
              "saleAmount": "87328428482.00",
              "reversalApprovedCount": "123",
              "reversalAmount": "12393423.00",
              "code39": "000",
              "RRN": "2034829434"
        }
        ]
      },
      "theRequestSerialNumber": "00000000-0000-0000-0000-00000000002c"
}
```

| Имя свойства | Тип | Описание |
|------------------------|---------|-------------------------------------------------------------------------|
| status | string | Статус операции закрытия дня |
| gate Id | long | Идентификатор шлюза по которому происходит закрытие дня |
| is Day Closing | boolean | Флаг закрытия дня, при значении true - шлюз заблокирован |
| gate Close Date | string | Дата закрытия дня шлюза |
| epnt Id | long | Свойство, присваемое банком терминалу при его настройке в системе банка |
| sale Approved Count | string | Число подтвержденных sale транзакций |
| sale Amount | string | Сумма по подтвержденным sale транзакциям |
| reversal Approved Count | string | Число подтвержденных reversal транзакций |
| reversal Amount | string | Сумма по подтвержденным reversal транзакциям |
| code39 | string | Результат закрытия, ответ банка на вызов процедуры закрытия гейта |
| RRN | string | Номер закрытия дня сгруппированный по ID терминала |
| the Request Serial Number | string | Серийный номер запроса закрытия дня |
Если во время выполнения процедуры закрытия дня пользователь посылает повторный запрос на закрытие дня с новым идентификатором запроса - сервер вернет ответ со статусом ‘error’ и с описанием ошибки. Использовать повторно идентификатор этого запроса для дальнейшего инициирования закрытия дня бессмысленно, т.к. статус ошибки - это финальный статус и идентификатор запроса всегда будет ассоциирован с этим запросом.
 
Пример структуры ответа следующий:
 
```text
{
      "response": {
        "status": "error",
        "errorCode": "99",
        "errorMessage": "gate is closing already"
      },
      "theRequestSerialNumber": "00000000-0000-0000-0000-000000000020"
}
```

| Имя свойства | Тип | Описание |
|------------------------|--------|-------------------------------------|
| status | string | Статус операции закрытия дня |
| error Code | string | Код ошибки |
| error Message | string | Описание ошибки |
| the Request Serial Number | string | Серийный номер запроса закрытия дня |
Если пользователь инициирует запрос с новым идентификатором запроса на терминал, по которому уже было закрытие дня, и часть ассоциированных с терминалом гейтов закрылись с ошибкой (и находятся в закрытом состоянии) - сервер пришлет ответ со статусом ‘error’ и соответствующим описанием ошибки.
 

> **Warning:** Для разрешения этой проблемы проведите операцию закрытия дня вручную в личном кабинете системы.

##### Инструмент снятия блокировки для шлюза

Если во время проведения удаленного закрытия дня, один или несколько шлюзов остались в заблокированном состоянии (в теле ответа при “status”: “finished” для шлюза - “is Day Closing”: true), Вы можете снять блокировку в личном кабинете системы и, при необходимости, закрыть день вручную.

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

> `pic1 close_day`
 
> `pic2 close_day`

На странице шлюза нажмите кнопку “Locks”, для вызова инструмента снятия блокировки.

> `pic9 close_day`
 
> `pic10 close_day`

В меню “Current locks” отображена текущая информация о блокировке шлюза:

* Lock session ID - идентификатор сессии блокировки.
* Start day closing date - дата начала закрытия дня.
* Bank terminal lock status - блокировка терминала для проведения траназкций (Blocked/Free).
* Initial gate job status - статус задачи по инициализации шлюза.
* Close day job status - статус задачи по закрытию шлюза.
* Is day closing - шлюз в стадии закрытия, т.е. находится ли в заблокированном состоянии (Y/N). Y - шлюз заблокирован, N - блокировки нет.

Доступны следующие команды снятия блокировки:

* CLEAR_TRANSACTION_LOCK - сбросить сессию из-за которой произошла блокировка.
* CLEAR_INIT_ATTEMPT - сбросить статус задачи по инициализации шлюза.
* CLEAR_CLOSING_DAY_ATTEMPTS - сбросить статус задачи по закрытию шлюза.
* CLEAR_CLOSING_DAY_FLAG - сбросить задачу по закрытию шлюза, снять блокировку.

Отметьте галочкой нужный пункт меню и нажмите кнопку “Update”.

После выполнения команды сброса, повторно откройте инструмент снятия блокировки и проверьте, что в меню “Current locks” изменился статус сбрасываемого параметра. Например, если шлюз был заблокирован, то после снятия блокировки параметр “Is day closing” = N.

##### Инструмент отладки для удаленного закрытия дня

Чтобы воспроизвести вызов API, введите все данные из исходного запроса, включая маркеры проверки подлинности. Не забудьте установить nonce и timestamp значения, которые Вы использовали. Запрос, подписанный с помощью OAuth, должен совпадать со значением в инструменте отладки ниже, вне зависимости от используемой библиотеки и языка программирования. Если подписи отличаются, значит в Вашем коде подписи OAuth есть ошибка.
 
<meta http-equiv="Cache-Control" content="no-cache">
<script src="../_static/js/oauth/sha1.js"></script>
<script src="../_static/js/oauth/oauth.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../_static/js/highlight/styles/default.css">
<script src="../_static/js/highlight/highlight.pack.js"></script>

<script>
$(document).ready (function(){ 
 $("#remote Tab a").click (function (e){
 	e.prevent Default();
 	$(this).tab('show');
 });
});
</script>

<script type="text/javascript">
		var curl Remote Text = "";
 
		var php Remote Text = "";
		
		var ruby Remote Text = "";
 function sign (form) {
	 var url = "";
		var sandbox = "";
		var params = "";
		
		var xhttp = new XMLHttp Request();
		xhttp.onreadystatechange = function() {
		if (xhttp.ready State == 4 && xhttp.status == 200) {
			if (url == "../_static/examples/PHP/params_with_header_get_PHP.txt"){
				php Remote Text = xhttp.response Text;}
			else {
				ruby Remote Text = xhttp.response Text;}
			}
		}
	
		url = "../_static/examples/PHP/params_with_header_get_PHP.txt";
		xhttp.open("GET", url, false);
		xhttp.send();
		url = "../_static/examples/Ruby/params_with_header_get_Ruby.txt";
		xhttp.open("GET", url, false);
		xhttp.send();
	
 var accessor = { consumer Secret: form.consumer Secret.value
 , token Secret : form.token Secret.value};
 var message = { method: form.http Method.value
 , action: form. URL.value
 , parameters: OAuth.decode Form (form.parameters.value)
 };
 for (var e = 0; e < form.elements.length; ++e) {
 var input = form.elements[e];
 if (input.name != null) 
 if (input.name.substring(0, 6) == "oauth_"){ 
 if (input.value != null) 
 if (input.value != "") 
 if (!(input.type == "checkbox" || input.type == "radio") || input.checked)
 {
 message.parameters.push([input.name, input.value]);
 params += " '" + input.name + "' => '" + input.value + "', \\n";
 }
			}else if (input.name.substring(0, 10) == "parameters"){
						
						var example = input.value.split('&');
 for (var i = 0; i < example.length; i++){
					 var split = example[i].split('=');
						params += " '" + split[0] + "' => '" + split[1] + "', \\n";
						}
					}
 }
 OAuth. Signature Method.sign (message, accessor);
 show Text("normalized Parameters", OAuth. Signature Method.normalize Parameters (message.parameters));
 show Text("signature Base String" , OAuth. Signature Method.get Base String (message));
 show Text("signature" , OAuth.get Parameter (message.parameters, "oauth_signature"));
 show Text("authorization Header" , OAuth.get Authorization Header("", message.parameters));

	curl Remote Text = "curl -H 'Authorization: " + OAuth.get Authorization Header("", message.parameters) + "' '" + form. URL.value + "?" + OAuth. Signature Method.normalize Parameters (message.parameters) + "'";
	
 show Text("curl Request" , curl Remote Text);
 	
	php Remote Text = php Remote Text.replace('{$Authorization}', OAuth.get Authorization Header("", message.parameters));
	php Remote Text = php Remote Text.replace('{$sandbox}', form. URL.value );
	php Remote Text = php Remote Text.replace("{$generated parameters with values code}", params);

	ruby Remote Text = ruby Remote Text.replace("{$generated parameters with values code}", params);
 ruby Remote Text = ruby Remote Text.replace('{$Authorization}', OAuth.get Authorization Header("", message.parameters));
	ruby Remote Text = ruby Remote Text.replace('{$sandbox}', form. URL.value);
	
	show Text("php Request" , php Remote Text);
	show Text("ruby Request" , ruby Remote Text);
	
 	$(document).ready (function() {
 $('pre code').each (function (i, block) {
 hljs.highlight Block (block);
 });
 }); 
	return false;
 }
 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
				element.innerHTML ="";
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }
 function fresh Timestamp() {
 document.request.oauth_timestamp.value = OAuth.timestamp();
 }
 function fresh Nonce() {
 document.request.oauth_nonce.value = OAuth.nonce(11);
 }
		 function copy To Clipboard (text) {
 var text Area = document.create Element("textarea");

 // Place in top-left corner of screen regardless of scroll position.
 text Area.style.position = 'fixed';
 text Area.style.top = 0;
 text Area.style.left = 0;

 // Ensure it has a small width and height. Setting to 1px / 1em
 // doesn't work as this gives a negative w/h on some browsers.
 text Area.style.width = '2em';
 text Area.style.height = '2em';

 // We don't need padding, reducing the size if it does flash render.
 text Area.style.padding = 0;

 // Clean up any borders.
 text Area.style.border = 'none';
 text Area.style.outline = 'none';
 text Area.style.box Shadow = 'none';

 // Avoid flash of white box if rendered for any reason.
 text Area.style.background = 'transparent';

 if (text == 'curl'){
	text Area.value = curl Remote Text;
 } else if ( text =='php'){
	text Area.value = php Remote Text;
 } else {
 text Area.value = ruby Remote Text;
 }
 document.body.append Child (text Area);

 text Area.select();

 try {
 var successful = document.exec Command('copy');
 var msg = successful ? 'successful' : 'unsuccessful';
 console.log('Copying text command was ' + msg);
 } catch (err) {
 console.log('Oops, unable to copy');
 }

 document.body.remove Child (text Area);

 
 }
</script>

<form name="request">

 
 <p></p>
 <input type="button" class="doc-button" style="font-size: 100%; padding: 2px 6px 3px 6px;" value="Sign" on Click="sign (document.request)"/>
 <p></p>
</form>

<ul class="nav nav-tabs" id="remote Tab">
 <li class="active">[CURL](#remoteCURL)</li>
 <li>[PHP](#remotePHP)</li>
 <li>[Ruby](#remote Ruby)</li>
 </ul>

 <button class="doc-button" onclick="copy To Clipboard('php')">Copy to clipboard</button>					
 <pre>
 <code class="php" id="php Request"></code>
 </pre>

 <button class="doc-button" onclick="copy To Clipboard('ruby')">Copy to clipboard</button>					
 <pre>
 <code class="language-ruby" id="ruby Request"></code>
 </pre>

### mPOS FAQ

#### Первоначальные действия при сбое работы терминала

В случае отсутствия описания ошибки в документации, при сбое работы терминала выполните следующие действия:

* Перезагрузить терминал, при необходимости, остальное оборудование.
* В случае ошибки сразу выгрузить логи с терминала.
* Проверить соединения: кабели, интернет и т.д.
* Переподключить терминал.
* Проверить настройки терминала в зависимости от типа подключения: USB/Ethernet.

Если проблема осталась, обратитесь в техническую поддержку.

#### Ошибка -01

No EMV final advice, autoreversed, Decline: 94029.

Не пришел EMV Final Advice на сервер. Причины:

* нет соединения с интернетом
* вытащили карту из терминала
* ошибка в ПО на терминале, в SDK или в приложении

Определить точную причину можно по логам. Найти в логах строчку с Invoice (например, у заказа 84822609 invoice - 461106A7-2E37-4D97-B594-8A1639691957).

Если в логах: CHIP_CARD_REMOVED, то вытащили карту.

Пример из логов:

```http
Web Apr 10 10:41:40 GMT +03:00 2019 DEBUG sdk.CardReaderPresenter PRESENTER:
PayneteasyReaderPresenter.cardReaderStateChanged(CardReaderEvent {state=SPIRE_48_TERMINATE_TRANSACTION_EVENT,message=<SpireTerminateTransaction48Event
   messageIdentifier = 48
   sequenceNumber    = 1
   reason            = 0x0E_14_CHIP_REMOVED
```

При этом деньги должны были вернуться автоматом.

#### Ошибка -02

Please try again later, Decline: 94030.

Причины:

* гейт заблокирован. Это видно по мониторингу на странице [мониторинга](https://gate.payneteasy.eu/paynet-ui/tools/monitoring). Строчка “Locked terminals - “. В значении указываются номера гейтов.
* подключены несколько терминалов (Spire или Miura) к одному гейту

Если заблокирован гейт, нужно зайти в личный кабинет системы, перейти в настройки гейта, выключить его, а затем включить.

 *Закрытие гейтов*

См. отчет Close Days Report в меню “Отчёты” - “Все отчёты”

#### Ошибка 2005 - PROCESSOR_OR_GATE_NOT_CONFIGURED_PROPERLY: Invalid rates

Проверить корректность настройки тарифов в системе. Тариф менеджера не может быть больше тарифа реселлера, банковский тариф не может быть больше тарифа реселлера или менеджера.
Транзакция при этом не успешна, можно исправить статус на “declined”.

#### Ошибка Attempt using magnetic strip if chip available

Проводят карту по магнитной полосе, а у нее есть чип.

#### Ошибка Gate 3822 got blocked by 83677493 order, nested error is blocked.by;83677492;-03

Попытка провести еще одну транзакцию, во время прохождения другой.

#### Ошибка Терминалы не проводят платежи

Проверить, не заблокирован ли гейт.

#### Оповещение Locked terminals - 1517,1537,1573,1574…

* заходим на страницу гейта
* проверяем, если ошибка закрытия дня
* если есть, значит банковский день закрылся неуспешно
* нажимаем на кнопку “Считать успешно закрытым”
* нажать на кнопку “Закрыть день”
* если день опять не закроется, нужно звонить в банк

#### Как снимать блокировку гейта

* перейти на страницу “Настройки” - “Поиск настроек”
* ввести номер гейта
* нажать на кнопку Disable, потом Enable

#### Платежи не проходят и даже попыток не видно

Проверить в меню “Инструменты” - “Интеграционная панель”

#### Оповещение для UNKNOWN статусов

Включить Failed session initiators в Tasks Будет приходить по 1-2 письма будет на каждый UNKNOWN.

#### Проверка вводил ли клиент пинкод или платеж прошел без ввода пинкода

В поле Order Description пишем как прошла транзакция например, с вводом PIN - будет так Order description:EMV_CONTACT_PIN_OFFLINE.

#### Перезагружается терминал во время оплаты

Проблема с питанием терминала по USB.

Если терминал подключен к блоку питания, то проблема в БП, надо заменить его.

#### Отображение оборотов по терминалу

Для правильной суммы лучше пользоваться Performance отчетом из меню “Отчёты” - “Все отчёты

Однако, нужно учитывать, что у каждой торговой точки мерчанта должен быть свой endpoint в разрезе ридеров мы не считаем, т.к. в течение дня ридер может сломаться и его заменят.

НЕЛЬЗЯ заводить один терминал в банке и подключать к нему больше одного ридера.

#### Как проверить заблокирован ли гейт

Экран “Инструменты” - “Monitoring” - “Tasks”. Строчка: Locked mobile terminals.

#### Ошибка 05 - Do not honour

Банк эмитент отклонил транзакцию. Причину отклонения нужно узнавать у банка, который выпустил карту.

#### Ошибка 88

Данная ошибка связана с некорректной работой ключа для бесконтактной оплаты. Для устранения данной ошибки необходимо связаться с нашей службой технической поддержки.

#### Очень долго грузится терминал. Примерно секунд 30-50. Выполнили 3+ентер и 2+ентер. Ситуация не изменилась

Терминал подбирает ip. Проверьте какой сейчас ip и зафиксируйте его в админке.

#### Идет подключение к терминалу и так остается в этом состоянии

Ошибка There was a problem while creating a connection to the remote service. У терминала настройки под Ethernet, а должны быть под usb, необходимо поменять настройки на самом терминале. Также возможно, что терминалу не хватает мощности: попробуйте подключить терминал по usb к компьютеру или еще куда-то, возможно не хватает мощности запитать терминал.

#### Что если с утра провести принудительную сверку итогов, то в 10 часов её уже не будет?

Сверка будет утром в любом случае.

#### Написано, что автоотмена, с клиента списались деньги, касса выдала ошибку

Терминал не дожидается статуса платежа (либо интернет либо еще что-то) в итоге отваливается по таймауту, хотя операция проходит. В таких случаях вероятнее всего проблема связана с тем, что используется версия SDK “sdk_version” = “0.2.27-3” и старее, в более поздних версиях, например ( 0.2.28-3) есть повторные запросы и таких ситуаций не происходит, плюс логируются все запросы статуса операции. SDK предоставляем мы, релиз её в вашем приложении не на нашей стороне. Информация о версии SDK доступна в reader-logs в первой строчке, например: “Creating manager version 0.2.27-3”.

Последние версии SDK можно посмотреть на сайте:

* iOS - [https://github.com/payneteasy/Payneteasy Reader/releases](https://github.com/payneteasy/Payneteasy Reader/releases)
* Android - [https://github.com/payneteasy/reader-example/wiki/Changelog](https://github.com/payneteasy/reader-example/wiki/Changelog)

#### Терминал не работает - деньги не списаны попробуйте другую карту. Неизвестная ошибка

Неправильно настроен терминал. Забыли указать Параметры / Редактирование / Smart Sale / SSL без ККМ = Да.

#### Подскажите, есть ли какие блокировки по терминалу? Не отражаются попытки оплаты и идут автоотмены

Почему терминалы PAX и Verifone иногда делали возврат: Все дело было в периодической (раз в час) проверке соединения с сервером. На всех терминала поменяли настройки - отключили проверку соединения, сделали ее только один раз, при включении. У нас сейчас практически все терминалы обновляются раз в день, какие не обновятся, тем нужно будет сделать 3+ENTER. Это касается только тех терминалов, которые работают по Ethernet, с USB подключением проблем нет.

#### Что означают обозначения EMV_CONTACT…?

* EMV_CONTACTLESS_SIGNATURE - бесконтактные способы оплаты картами до 1000 рублей, а также Apple Pay, Google Pay, и др.
* EMV_CONTACT_PIN_OFFLINE - оплата картой с чипом и вводом пин-кода.
* EMV_CONTACTLESS_PIN_ONLINE - бесконтактные способы оплаты картами от 1000 рублей с вводом пин-кода.
* EMV_CONTACT_SIGNATURE - если карта отказывается проверять пинкод у держателя карты, требуется подпись клиента на чеке в подтверждение операции.
* MAGNETIC_STRIPE_SIGNATURE - оплата картой с помощью магнитной ленты, предполагается подпись клиента на чеке. Также, возможно, с таким кодом пройдёт оплата телефоном Samsung с технологией эмуляции магнитной ленты.

#### Подскажите, есть ли какие блокировки по терминалу? Не отражаются попытки оплаты и идут автоотмены

В логах это проявляется так:

* 2018.10.10 17:05:32 INFO unipos Проверка соединения по расписанию
* 2018.10.10 17:05:35 DEBUG TACL ========= Сборка сообщения =========
* 2018.10.10 17:05:35 DEBUG TACL ISO 000 : 800

#### <PNEReader Event: state=Unknown (22), self.message=192.168.2.255-192.168.2.156:27015>…

<PNEReader Event: state=Unknown (22), self.message=192.168.2.255-192.168.2.156:27015>
2018-10-22 18:20:47.802 +03:00 -[Inpas Reader Manager stop],105 - Inpas Reader Manager.stop()
2018-10-22 18:20:47.803 +03:00 -[Inpas Reader Manager do Disconnect With Message:],144 - Inpas Reader Manager closing streams
2018-10-22 18:20:47.805 +03:00 -[Inpas Reader Manager Delegate on Reader Event:],260 - Inpas Reader Manager Delegate.presenter state Changed:
<PNEReader Event: state=Not Connected, self.message=(null)>

Проблема может быть связана со старой версией SDK. Информация о версии SDK доступна в reader-logs в первой строчке, например: “Creating manager version 0.2.27-3”

Последние версии SDK можно посмотреть на сайте:

* iOS - [https://github.com/payneteasy/Payneteasy Reader/releases](https://github.com/payneteasy/Payneteasy Reader/releases)
* Android - [https://github.com/payneteasy/reader-example/wiki/Changelog](https://github.com/payneteasy/reader-example/wiki/Changelog)

#### Терминал не работает - деньги не списаны попробуйте другую карту. Неизвестная ошибка

Это проявляется выводом сертификата ssl в логах:

* Sat Oct 20 22:33:36 GMT+03:00 2018 DEBUG sdk. Sa63Connection16Eve Connection event is Sa63Connection16Event{

operation = OPEN
host = 185.15.175.23
port = 20002
\_91_pulsar_tags = ‘CA:—–BEGIN CERTIFICATE—–
MIIDTTCCAj Wg AwIBAgIJALYx Pmm QmP+xMA0GCSqGSIb3DQEBCwUAMB4xHDAa BgNV

#### При попытке провести оплату пишет - “нет соединения с терминалом”

Проверить, включен ли Bluetooth.

#### При попытке проведения - ошибка, что банк отклонил платеж, но в списке заказов нет этого платежа

Зайти в меню “Инструменты” - “Интеграционная панель” и првоерить запросы по терминалу (Endpoint)

В старых версиях программы Cassby может высылаться нулевая сумма.

#### Не удалось отменить транзакцию

Проверить, не заблокирован ли гейт.

Если банк возвращает двухбуквенный код ответа, то следует обратиться в банк с номером RRN и кодом ответа банка.

#### В Интеграционной панели в ЛК ошибка - Signature verification failed.

Ошибка связана с подписью запроса. Проверьте в настройках терминала endpoint, login, control key.

### mPOS SDK for Android and Java

#### Introduction

Payneteasy mPOS SDK is a mobile payment software & hardware package that allows to quickly and easily start offering a mobile payment service. Usage of an affordable mobile point of sale (mPOS) terminal allows Connecting party to extend their business with in-person non-cash payments.

```plantuml
@startuml
left to right direction
rectangle "Mobile Device" {
(mPOS SDK)  #ffe6cc;line:black;line.dotted
(Mobile App)
}
(Payneteasy) -- (mPOS SDK)
(Payneteasy) - (Acquirer Bank)
(mPOS SDK) -- (Mobile App)
(mPOS device) - (mPOS SDK)
@enduml
```

Payneteasy Reader SDK provides fast integration with [mPOS](https://doc.payneteasy.com/integration/mpos_api_index.html.md) terminals in mobile apps.

Features

- Runs both on Android and Java
- MSR, EMV Contact, EMV Contactless transactions
- Signature or PIN based transactions
- Remote key injection
- Remote firmware update
- Remote mPOS configuration
- Certified with Open Way. The first mobile POS Chip&PIN solution in Russia - [news_card.jsp](https://www.openwaygroup.com/news_card.jsp?dcion=908&rgn=1&lng=1)
- Custom LCD messages for all stages (Miura only)
- Unified API for all readers
- Implemented [Payneteasy Server API](https://doc.payneteasy.com/integration/mpos_api.html.md)
- Many transaction types: sale, preauthorization, capture, cancel, reversal, partial reversal and etc.

> **Note:** Requirements: SDK supports target deployment of Android from 2.2 and Oracle JVM (tested on 1.8)

#### Supported Terminals

| Vendor | Model | Connectivity |
|----------|------------------|------------------------------------------------------------------------------------------------------------------------------------------------|
| Miura | M006, M007, M010 | Supports MSR, Contact, Contactless transactions. With or without PIN. Remote keys injection, remote configuration and remote MPI and OS update |
| Spire | SPm2 | Bluetooth |
| Verifone | Vx820 | Ethernet, USB, RS232 |
| PAX | SP30 | Ethernet, USB, RS232 |

> **Note:** All terminals support remote configuration and firmware update.

> **Warning:** Deprecated from the 1st of January 2015:

GD Seed: Integrated with the official SDK.
 
GD Seed: Own SDK. With memory and performance optimization.
 
ID Tech Unimag II: Integrated with the official SDK.
 
ID Tech Unimag II: Own SDK. Memory and performance optimization. Extends supported phone models.
 
Bluebamboo P25.
 

> **Warning:** Evaluated:

Datecs DRD50, DRD10
 
Datecs MPED400, Bluepad 50
 
Wizar POS
 
BBPOS
 

#### Integration

The SDK includes a maven repository - [http://paynet-qa.clubber.me/reader/maven/](http://paynet-qa.clubber.me/reader/maven/)
For Miura Shuttle model: Use TEST on emulators for events.

##### Setup maven

[Android Maven repository can be found here](https://github.com/payneteasy/reader-example). Add the repository to pom.xml:

```text
<repository>
  id>reader-repo</id>
  <name>reader repo</name>
  <url>http://paynet-qa.clubber.me/reader/maven</url>
</repository>`
```

##### Setup gradle

[Android Gradle repository can be found here](https://github.com/payneteasy/reader-example-gradle). Add the following to repositories section:

```text
 repositories {
...
   maven { url "https://jitpack.io" }
   maven { url "http://paynet-qa.clubber.me/reader/maven" }
...
 }
```

- Add the following to dependencies:

```text
dependencies {
...
  def readerVersion = // check the latest version :ref:`here<https://github.com/payneteasy/reader-example/wiki/Changelog>`
  compile 'com.payneteasy.android.reader:api:' + readerVersion
  compile ('com.payneteasy.android.reader:lib:' + readerVersion)

  compile 'com.payneteasy.android.reader.readers:readers-common-bluetooth:' + readerVersion
  compile ('com.payneteasy.android.reader.readers:readers-miura:' + readerVersion) {
      exclude group:'junit', module:'junit'
  }
...
}
```

For additional details, please refer to the complete [Gradle example available here](https://github.com/payneteasy/reader-example-gradle).

##### For Bluetooth Readers (Android)

Add the following to Android Manifest.xml:

```text
<uses-permission android:name="android.permission.BLUETOOTH"/>
   <uses-permission android:name="android.permission.BLUETOOTH_ADMIN"/>
```

##### For USB terminals (Android)

- Add new file res/xml/device_filter.xml:

```text
<?xml version="1.0" encoding="utf-8"?>
<resources>

  
  <usb-device vendor-id="4660" product-id="257" class="255" subclass="0" protocol="0"/>

  
  <usb-device vendor-id="4554" product-id="537" class="10" subclass="0" protocol="0"/>

</resources>
```

- Add any activity element to Android Manifest.xml:

```text
<intent-filter>
      <action android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" />
  </intent-filter>
  <meta-data  android:name="android.hardware.usb.action.USB_DEVICE_ATTACHED" android:resource="@xml/device_filter" />`
```

- Add to the activity:

```text
public class MainActivity extends Activity {

   private final UsbPermissionResolver usbPermissionResolver = new UsbPermissionResolver();

   @Override
   protected void onCreate(Bundle savedInstanceState) {
       super.onCreate(savedInstanceState);
       ...
       usbPermissionResolver.checkPermission(getIntent(), this);
   }

   @Override
   protected void onNewIntent(Intent intent) {
       super.onNewIntent(intent);
       usbPermissionResolver.checkPermission(intent, this);
   }

   @Override
   protected void onDestroy() {
       super.onDestroy();
       usbPermissionResolver.unregister(this);
   }

   ...

   }
```

> **Note:** Please see [this commit](https://github.com/payneteasy/reader-example-gradle/commit/2aa02c47f38cef4f3a673e98fc5d5ecb98720656) for more information.

##### For Miura (Java)

Please see the example app-2 how to run and assemble the application for Miura Readers to run on JVM.

app-3-webstart shows how to run the application from a browser via Java Web Start:

##### Sample Code

Implement the IReader Presenter interface:

```text
@Override
  public ProcessingContinuation onCard(BankCard bankCard) {

      setStatus("onCard: %s", bankCard);

      return ProcessingContinuation.Builder
              .startSaleOnline()
              .processingBaseUrl  ( Config.SERVER_BASE_URL)
              .merchantLogin      ( Config.MERCHANT_LOGIN )
              .merchantControlKey ( Config.MERCHANT_KEY   )
              .merchantEndPointId ( Config.END_POINT_ID   )
              .orderDescription   ( "test description"    )
              .orderInvoiceNumber ( "invoice-"+System.currentTimeMillis())
              .orderMerchantData  ( "custom merchant data for a internal use")
              .customerPhone      ( "+7 499 918-64-41"    )
              .customerEmail      ( "info@payneteasy.com" )
              .customerCountry    ( "RUS"                 )
              .listener(new IProcessingStageListener() {
                  @Override
                  public void onStageChanged(ProcessingStageEvent aEvent) {
                      setStatus("processing: %s", aEvent);
                  }
              })
              .build();

  }

  @Override
  public void onReaderSerialNumber(String aKsn) {
      setStatus("onReaderSerialNumber: %s", aKsn);
  }

  @Override
  public void cardReaderStateChanged(CardReaderEvent cardReaderEvent) {
      setStatus("cardReaderStateChanged: %s", cardReaderEvent);
  }

  @Override
  public void onCardError(CardError cardError) {
      setStatus("onCardError: %s", cardError);
  }

  @Override
  public void onReaderNotSupported(CardReaderProblem aProblem) {
      setStatus("onReaderNotSupported: %s", aProblem);
  }

  @Override
  public void onAudioData(short[] shorts, int i) {
      // for visualization
  }

  @Override
  public ConfigurationContinuation onConfiguration() {
      return new ConfigurationContinuation.Builder()
              .configDir              ( new File(activity.getFilesDir(), "miura-config"))
              .configurationBaseUrl   ( Config.SERVER_CONFIG_URL  )
              .merchantLogin          ( Config.MERCHANT_LOGIN     )
              .merchantControlKey     ( Config.MERCHANT_KEY       )
              .merchantEndPointId     ( Config.END_POINT_ID       )
              .build();
  }
```

> **Note:** Fill the Config. MERCHANT_LOGIN, Config. MERCHANT_KEY, Config. END_POINT_ID with your own values.

Starts the Reader Manager:

```text
CardReaderInfo cardReader = CardReaderInfo.TEST;
BigDecimal amount = new BigDecimal(1);
String currency = "RUB";

SimpleCardReaderPresenter presenter = new SimpleCardReaderPresenter(this, statusView);
cardReaderManager = CardReaderFactory.findManager(this, cardReader, presenter, amount, currency, null);`
```

Deal with card Reader Manager:

- ICard Reader Manager.start Sale Session() starts a sale session
- ICard Reader Manager.stop Session() stops a session and releases resources

#### Useful Links

- Additional samples can be provided by request.
- [Other releases can be found here](https://github.com/payneteasy/reader-example/wiki/Changelog).

### mPOS SDK for iOS

#### Introduction

Payneteasy mPOS SDK is a mobile payment software & hardware package that allows to quickly and easily start offering a mobile payment service. Usage of an affordable mobile point of sale (mPOS) terminal allows Connecting party to extend their business with in-person non-cash payments.

```plantuml
@startuml
left to right direction
rectangle "Mobile Device" {
(mPOS SDK)  #ffe6cc;line:black;line.dotted
(Mobile App)
}
(Payneteasy) -- (mPOS SDK)
(Payneteasy) - (Acquirer Bank)
(mPOS SDK) -- (Mobile App)
(mPOS device) - (mPOS SDK)
@enduml
```

Payneteasy Reader SDK provides fast, ADVT & M-TIP compliant integration with [mPOS](https://doc.payneteasy.com/integration/mpos_api_index.html.md) terminals in mobile apps. SDK includes header files and a single static library.

#### Supported Terminals

| Vendor | Model | Connectivity |
|----------|------------------|-----------------------|
| Miura | M006, M007, M010 | Bluetooth, USB, Wi-Fi |
| Spire | SPm2, SPm20 | Bluetooth |
| Verifone | Vx820 | Ethernet, USB, RS232 |
| PAX | SP30, D200 | Ethernet, USB, RS232 |

> **Note:** Requirements: Payneteasy Reader SDK supports target deployment of iOS version 7.0+ and instruction set armv7+ (including 64-bit), x86_64, i386 (for emulator).

#### Integration

##### Add the SDK to the project

Add the following to Podfile:

```text
pod "PayneteasyReader", :git => 'git@github.com:evsinev/PayneteasyReader.git', :tag => '$VERSION'
```

Please change $VERSION to the latest version from releases list for [IOS](https://github.com/payneteasy/Payneteasy Reader/releases) or [Android](http://paynet-qa.clubber.me/reader/maven/com/payneteasy/android/reader) respectively.

##### For Miura, Spire and Pax

Add the following to \*-Info.plist:

```text
<key>UISupportedExternalAccessoryProtocols</key>
<array>
  <string>com.miura.shuttle</string>
  <string>com.thyron</string>
  <string>com.paxsz.ipos</string>
</array>
```

##### Sample Code

Implement the PNEReader Presenter protocol:

```text
- (void)stateChanged:(PNEReaderEvent *)aEvent {
 // displays reader status
 // see an example at https://github.com/payneteasy/ReaderExample/blob/master/ReaderExample/PaymentModule/PaymentPresenter.m#L69
}

- (PNEProcessingContinuation *)onCard:(PNECard *)aCard {
  // provide payneteasy.com account info
  PNEProcessingContinuation * continuation = [PNEProcessingContinuation
          continuationWithBaseUrl:@"https://sandbox.payneteasy.com/paynet"
                    merchantLogin:MERCHANT_LOGIN
                      merchantKey:MERCHANT_KEY
               merchantEndPointId:END_POINT_ID
               orderInvoiceNumber:[[NSUUID UUID] UUIDString]];

  return continuation;
}

- (void)onCardError:(PNECardError *)aError {
  // deal with the error
  // see an example at https://github.com/payneteasy/ReaderExample/blob/master/ReaderExample/PaymentModule/PaymentPresenter.m#L93
}

- (void)onProcessingEvent:(PNEProcessingEvent *)aEvent {
  // wait for Result event
  // see an example at https://github.com/payneteasy/ReaderExample/blob/master/ReaderExample/PaymentModule/PaymentPresenter.m#L96
}

- (PNEConfigurationContinuation *)onConfiguration {
  return [[PNEConfigurationContinuation alloc]
          initWithBaseUrl:@"https://paynet-qa.clubber.me/paynet/rki"
            merchantLogin:_payment.merchantLogin
              merchantKey:_payment.merchantKey
       merchantEndPointId:_payment.merchantEndPointId
             merchantName:_payment.merchantName
  ];
}
```

Start Reader Manager:

```text
PNEReaderFactory *factory = [[PNEReaderFactory alloc] init];
PNEReaderInfo *reader = [PNEReaderInfo infoWithType:PNEReaderType_MIURA_OR_SPIRE];
// Note: manager must be a property or a field or a static local variable, to prevent an elimination
manager = [factory createManager:reader
                        amount:[NSDecimalNumber decimalNumberWithString:@"1.00"]
                      currency:@"RUB"
                     presenter:self];
[manager start];
```

##### Useful Links

- Additional samples can be provided by request.
- Other releases can be found [here](https://github.com/payneteasy/Payneteasy Reader/releases).

##### Test Environment

| Amount | Status | Stage |
|----------|----------|--------------------------------------------------------------------------------------------|
| 1 | APPROVED | Purchase, Final Advice |
| 2 | DECLINED | Purchase |
| 3 | APPROVED | Purchase |
| 4 | DECLINED | Purchase, Final Advice |
| 1000.01 | APPROVED | Purchase, Final Advice with PIN Online Test. Only test cards can be used in test purposes. |

> **Note:** Any card can be used.

If card asks ARQC then host replies with Authorisation Response Code = ‘Z3’ (Unable to go online, offline declined).

### mPOS Terminals

### mPOS Test

#### Payneteasy QA Server

Payneteasy QA Environment - it is the [Sandbox server](https://paynet-qa.clubber.me/paynet) for connectivity issues testing. Server behaviour depends on the amount:

1.00 - A regular payment without any network error - result is APPROVED.
 
Other amounts - result is DECLINE.
 

Please see error types below.

| Amount | Result | Description |
|----------|----------|--------------------------------------------------------|
| 1 | APPROVED | A regular payment without any network error. |
| 1.01 | APPROVED | OrderID was nor received on sale stage. |
| 5 | APPROVED | Timeout (70 seconds) for the first status poll. |
| 5.01 | APPROVED | Timeout (70 seconds) for sale. |
| 5.02 | APPROVED | Timeout (70 seconds) for advice. |
| 5.03 | APPROVED | Timeout (70 seconds) for the status poll after advice. |
| 6 | APPROVED | HTTP Status 503 for sale. |
| 6.01 | APPROVED | HTTP Status 503 for the first status poll. |
| 6.02 | APPROVED | HTTP Status 503 for advice. |
| 6.03 | APPROVED | HTTP Status 503 for the status poll after advice. |
<script src="../_static/js/generate_card_number.js"></script>
<script src="../_static/js/crypto-js/sha1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../_static/js/highlight/styles/default.css">
<script src="../_static/js/highlight/highlight.pack.js"></script>

<script>hljs.init Highlighting On Load();</script>

<script type="text/javascript">
 $(document).ready (function(){
 $("#sha1Tab a").click (function (e){
 e.prevent Default();
 $(this).tab('show');
 });
 });
</script>

<script type="text/javascript">
 function sign (form) {
 var amount Info = document.get Element By Id("amount Warning");
 var signed Text = "";
 for (var e = 0; e < form.elements.length; ++e) {
 var input = form.elements[e];
 if (input.name != null)
 if (input.name.substring(0, 5) == "sha1_")
 if (input.value != null)
 if (input.value != "")
 if (!(input.type == "checkbox" || input.type == "radio") || input.checked)
 {
 if (input.name == "sha1_amount"){
 var amount To Fix = input.value \* 100;
 var fixed Amount = amount To Fix.to Fixed(0);
 if (fixed Amount != amount To Fix)
 { amount Info.innerHTML = amount Info.innerHTML.replace("​", "Possible floating point imprecision (for more information check Floating Point Math)");}
 else {amount Info.innerHTML = amount Info.innerHTML.replace("Possible floating point imprecision (for more information check Floating Point Math)", "​");}
 signed Text = signed Text + fixed Amount;}
 else
 {signed Text = signed Text + input.value;}
 }
 }
 show Text("signedvalue" , signed Text);
 show Text("sha1value" , CryptoJS.SHA1 (signed Text));

 return false;
 }

 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }
</script>

<ul class="nav nav-tabs" id="sha1Tab">
 <li class="active">[1.00](#100)</li>
 <li class="">[1.01](#101)</li>
 <li class="">[5.00](#500)</li>
 <li class="">[5.01](#501)</li>
 <li class="">[5.03](#503)</li>
 <li class="">[6.00](#600)</li>
 <li class="">[6.01](#601)</li>
 <li class="">[6.02](#602)</li>
 <li class="">[6.03](#603)</li>
</ul>

### mPOS Test

#### Сервер Sandbox

В зависимости от суммы он ведет себя по-разному:

1.00 - обычный платеж без ошибок в сети. Результат APPROVED
 
другие суммы - Результат: DECLINED
 

#### Сервер Qa

Специальный сервер для тестирования различных ошибок связи: https://paynet-qa.clubber.me/paynet
 
Сервер принимает любые значения для endpoint, merchant login и merchant control key.
 

В зависимости от суммы он ведет себя по-разному:

1.00 - обычный платеж без ошибок в сети. Результат APPROVED
 
1.01 - не был получен идентификатор платежа в ответе на sale. Результат: APPROVED
 
5.00 - timeout (70 секунд) на первый status. Результат: APPROVED
 
5.01 - timeout (70 секунд) на sale. Результат: APPROVED
 
5.02 - timeout (70 секунд) на advice. Результат: APPROVED
 
5.03 - timeout (70 секунд) на status после advice. Результат: APPROVED
 
6.00 - HTTP Status 503 на sale. Результат: APPROVED
 
6.01 - HTTP Status 503 на первый status. Результат: APPROVED
 
6.02 - HTTP Status 503 на advice. Результат: APPROVED
 
6.03 - HTTP Status 503 на status после advice. Результат: APPROVED
 

Все платежи должны в конце выдать статус APPROVED.

### OAuth Request Authentication Method

#### OAuth HMAC-SHA1

To generate request with OAuth HMAC-SHA1 authentication:

1. [Generate Signature](#hmac-sha1-signature-generation),
2. [Generate Headers](#hmac-sha1-headers-generation),
3. [Generate Request](#hmac-sha1-request-generation).

##### OAuth HMAC-SHA1 Signature Generation

To prepare the Signature Base String do the following steps:

1. Gather all request body parameters and OAuth parameters (oauth_consumer_key, oauth_nonce, oauth_signature_method, oauth_timestamp, oauth_version):
 For oauth_consumer_key use a merchant login provided by Payment Gateway, ex. merchantlogin.
 
 For oauth_nonce generate unique random nonce, ex. y3qlvMPky7g.
 
 For oauth_signature_method set HMAC-SHA1.
 
 For oauth_timestamp header get current timestamp in seconds, ex. 1669966913.
 
 For oauth_version set 1.0.
 
 Parameter oauth_signature is not included in request body parameters (only in OAuth header).
 
2. Percent-encode value of each gathered on step 1 parameter. See [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) for reference. The unreserved characters can be encoded, but should not be encoded. The reserved characters have to be encoded, for example: `%` is encoded to `%25`, `/` is encoded to `%2F`, `=` is encoded to `%3D`.
3. Sort all gathered on step 1 parameters together with their values in lexicographical order by parameter name.
4. Concatenate all gathered on step 1 parameters and their values using & and = in the following way:
 
 `object1=value Of Object1&object2=value Of Object2...`
 
 Concatenated parameters string example:
 
   ```http
   client-order-id=1234567890&oauth_consumer_key=merchantlogin&oauth_nonce=y3qlvMPky7g&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1669966913&oauth_version=1.0&sending-card-ref-id=7654321
   ```
5. Percent-encode each element (POST, URL, concatenated parameters) and construct Signature Base String with POST&URL&parameters structure (as documented in OAuth [A.5.1.](https://oauth.net/core/1.0a/#sig_base_example)).
 
 Signature Base String Example:
 
   ```text
   POST&https%3A%2F%2Fgate.payneteasy.eu%2Fpaynet%2Fapi%2Fv2%2Fpan-eligibility%2Fsend%2FENDPOINTID&client-order-id%3D1234567890%26oauth_consumer_key%3Dmerchantlogin%26oauth_nonce%3Dy3qlvMPky7g%26oauth_signature_method%3DHMAC-SHA1%26oauth_timestamp%3D1669966913%26oauth_version%3D1.0%26sending-card-ref-id%3D7654321
   ```
6. Sign the Signature Base String with HMAC-SHA1. The signing key is the concatenation of consumer secret (Merchant control key) + & + token secret (empty string).
 
 HMAC-SHA1 Key Example:
 
   ```text
   11111111-1111-1111-1111-111111111111&
   ```
7. Encode the signed string to Base64 to get signature for API.
 
 Java HMAC-SHA1 Signature Generation Example:
 
   ```java
   package com.Payneteasy;

   import org.apache.commons.codec.binary.Base64;
   import javax.crypto.Mac;
   import javax.crypto.spec.SecretKeySpec;
   import java.security.InvalidKeyException;
   import java.security.NoSuchAlgorithmException;

   public class HMAC_SHA1 {
      private static final String HMAC_SHA1_ALGORITHM = "HmacSHA1";

      public static String calculateHMAC(String data, String key) throws NoSuchAlgorithmException, InvalidKeyException {
         SecretKeySpec signingKey = new SecretKeySpec(key.getBytes(), HMAC_SHA1_ALGORITHM);
         Mac mac = Mac.getInstance(HMAC_SHA1_ALGORITHM);
         mac.init(signingKey);
         return Base64.encodeBase64String(mac.doFinal(data.getBytes()));
      }
   }
   ```

 Signature will look like following string:
 
   ```text
   d/IPlITUmPcniwjA7Vckjr6WQeE=
   ```

##### OAuth HMAC-SHA1 Headers Generation

A request with OAuth HMAC-SHA1 authentication method must contain next headers:

* content-type=application/x-www-form-urlencoded
* Authorization: OAuth

OAuth header must contain the same OAuth parameters and values which were included in signature base string (oauth_consumer_key, oauth_nonce, oauth_signature_method, oauth_timestamp, oauth_version). Add signature as value of parameter oauth_signature to header Authorization. All values of parameters in OAuth header must be in quotes (See OAuth [5.4.1.](https://oauth.net/core/1.0a/#auth_header)) with the following structure: parameter=”value” and be separated by mandatory comma (,) and optional space. OAuth realm parameter is optional.
 
Authorization Header Example (Header is line-separated for display purposes):
 
```http
Authorization: OAuth
oauth_consumer_key="merchantlogin",
oauth_nonce="y3qlvMPky7g",
oauth_signature="d/IPlITUmPcniwjA7Vckjr6WQeE=",
oauth_signature_method="HMAC-SHA1",
oauth_timestamp="1669966913",
oauth_version="1.0"
```

> **Note:** Since headers are not usually encoded, the values of oauth parameters (especially oauth_nonce and oauth_signature) should be percent-encoded separately before being added to Authorization header.

##### OAuth HMAC-SHA1 Request Generation

1. Use headers from previous section,
2. Add request parameters to body,
3. Percent-encode and send the request.

Example of Request:

```text
Request method:      POST
Request URI: https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/send/1111
Headers: Authorization=OAuth realm="",oauth_version="1.0",oauth_consumer_key="merchantlogin",oauth_timestamp="1669966913",oauth_nonce="y3qlvMPky7g",oauth_signature_method="HMAC-SHA1",oauth_signature="d%2FIPlITUmPcniwjA7Vckjr6WQeE%3D"
         Accept=*/*
         Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Body: client-order-id=1234567890&oauth_consumer_key=merchantlogin&oauth_nonce=y3qlvMPky7g&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1669966913&oauth_version=1.0&sending-card-ref-id=7654321
```

Example of CURL Request:

```text
curl -H '
   Authorization: oauth_version="1.0",
   oauth_consumer_key="merchantlogin",
   oauth_timestamp="1669966913",
   oauth_nonce="y3qlvMPky7g",
   oauth_signature_method="HMAC-SHA1",
   oauth_signature="d%2FIPlITUmPcniwjA7Vckjr6WQeE%3D"
' --data '
   client-order-id=1234567890
   &oauth_consumer_key=merchantlogin
   &oauth_nonce=y3qlvMPky7g
   &oauth_signature_method=HMAC-SHA1
   &oauth_timestamp=1669966913
   &oauth_version=1.0
   &sending-card-ref-id=7654321
' 'https://gate.payneteasy.eu/paynet/api/v2/pan-eligibility/send/ENDPOINTID'
```

#### OAuth RSA-SHA256

To generate request with OAuth RSA-SHA256 authentication:

1. [Generate Key Pair](#rsa-sha256-generating-key-pair),
2. [Generate Signature](#rsa-sha256-signature-generation),
3. [Generate Headers](#rsa-sha256-headers-generation),
4. [Generate Request](#rsa-sha256-request-generation).

##### Generating Key Pair

To authorize future requests with RSA-SHA256, generate the key pair:

* A PRIVATE key to sign the request. This private key must be kept secret from everyone.
* A PUBLIC key to verify that the request was signed with the respective private key. Send it to support manager.

There are two ways to generate the key pair:

* Using a [Key-Pair-Factory tool](https://github.com/payneteasy/key-pair-factory) - the native cross-platform desktop app.
* Using [OpenSSL library](#rsa-sha256-generating-key-pair-via-openssl).

###### Generating Key Pair via OpenSSL

To generate keys download latest version of [openssl](https://www.openssl.org/) and run following commands:

```bash
openssl genpkey -algorithm RSA -out private_key_pkcs_8.pem -pkeyopt rsa_keygen_bits:4096
openssl rsa -pubout -in private_key_pkcs_8.pem -out public_key.pem
```

Use different keys for production and for testing purposes to avoid compromise.

To use request builders in documentation, get the private key in PKCS#1 container. It should be unencrypted RSA private key in PKCS#1 PEM text format. To get it use the following command:

```bash
openssl rsa -in private_key_pkcs_8.pem -out private_key_pkcs_1.pem
```

> **Note:** **For OpenSSL v3+ (tested on v3.0.5)**, use the following command instead:

```bash
openssl rsa -traditional -in private_key_pkcs_8.pem -out private_key_pkcs_1.pem
```

The resultant PKCS#1 RSA private key will start with —–BEGIN RSA PRIVATE KEY—–. For production purposes any format of the key supported by Connecting Party software can be used. Request builders in documentation support key length up to 4096. Example of the PKCS#1 RSA private key:

```bash
-----BEGIN RSA PRIVATE KEY-----
MIIJKQIBAAKCAgEA16QK2iwgYUbMr2GqSbaS0PQZKF2DkstSj0dakW+hASTz5Ams
R5sDnurfeR4m+Htaxiv69MMdvoDLuCmZE8KQzsEOZovZ9UYSh9CKK4/FzQSZ8ZDP
8cpKLN7/gitWiM14iuC9Pi74TTLeg7PuGjeoc0jUs0WMf7sV6uzfZwvqYgUVRljY
gscwDRiTSGJQumQtanCs/LMIkxouThLztSSEmHhhEz2aWOomqR5hHO+HJ4I1AfET
V7VpKJ4c1+zMesDfpDxZ8VpQpno9iikFG64MigDFmBeskI6q15tBwbROYSfqNEmG
LwhYQ+SXnojueazkSJ45CeQRh6dn3GgD7kex2N3lK97qpqDcWOLqcsbe+ZyTGALn
WGzTZWjleO+yrdE6awD34kUYVnzD/9WvdYqpH2pXBDqOIXu6lm4gLe5pKTRiFEc+
TjgVb34tJGEERkrvqktSEmRQzMgZQnZk/5//7+csUIcSPmqdUn5oB6ngVueZkk7v
wtL6dcCxr5isWgXQEO+oYbt72Ns5RjLVWiXWv2ZNFd+iR4O6+etBxYNz+mg/2B5c
PO8NWyvvFlaBUu4I5GG1XntBGWncKQiZ49WCvLcYEbSfUEkWLj6zqJaDS/buT3jU
rWQ0WEI8G1HnTQp0cqmx9WpXDLx4n3ytRjHuHe3ND9AYE28yhfFY5baIU3UCAwEA
AQKCAgAC4QrQDOTFx7c15DzszQY6yfeIBW+bRyGsDgzUgkQJCuBCvCpTrmsm9QXU
zSVCDguRN8ca+3vrLjcKF2wWynM6f3NcxSM81hmrPIqLuFiwuw3/HqrYFJZW8QdC
SqfWHcAtQoDkUqY4CaTU51MXgIS8PU2xsw0EK5BIWa9F5e/ULTMyhD8nx9cJZbmZ
rs5bHrlIgYadvRoxNJlHq5MbaQhoLLtHEXx9EWtAuModI8mPKnrgssJKWn6z7yB9
dYjpXqfdvnyI72bCQkGOFaweyX0bXpVEyZQhPfZj+IuxNWIShADpf83N1POwvF2V
3Ugp0bgejBZA3o2pXP/S/oSG6ugh8dZHfa8vkw0x5N28393IzIMpzwE2EnsBidN1
ca7NwDpmpUyuULSpi3YoViUYY1i4Mwngv2XQdkbvoGusQwgWoNrppmDKxlL5qEBf
lIPCZAgZSR79KHYw2VOzkm84hu0jDXMthpt9A2gLkRhGnGgb4n5KzyCpY9iuFK2w
CO5FdjloXOjRLZb7G1JCeU6Qh0kjSE7seh9ltyo+VsWOLx4UwVOYGCMAF45yO0wF
/MJdYoUt1vC5G/DK8itTTjwb/xPlGDiC441TOReWVwF6n36+shb6szlI2EmqKBkp
2Sr5xQ5VNZkcG2W/BUF7+n8Rvisu17TyW0HmwDEBDfJQzgzgpQKCAQEA7RpBNVBH
Jx8gR7hQdbyi4/6U5KiYorkzuoK4KkjRWJfqJvp9uGZS2vDwOoIC8kCAXMwu3OCI
U0xkDvH7bb/qedn0IG7+72FUCKlxqkMk4lv03zE9yUPcYNT+w573uh+rXQ/mcsFF
+aBtupRZiDqqd4vuvjTpjw5Q4tyk/lxZfbe10S2NyxY4dZsbm8gl0SypLs/rLYjZ
8ZntRpZozIWoenrF3AnvtR114WBDpBVwSJ9KNd8xB5Fufc9TqsZ/EKPjDVrn2Sq2
Lt/xKSopwxPyIhKG1zmAeYhv8Q+GYUOQYCfBj2opDC3AOxANw2j9M8nYjCMDmPaP
5iDCUla35srp/wKCAQEA6NPj8auPGGFen2ZJoydpEPKgU3zAdv05VlKVIvbA9c+Y
oy7zNhnNw0PCkkYpB9jPGvpdn6KFh2ZTU/mgmIysKriLcLN4gKho7JUCU3kvg1mv
zJiz/5fR0xCCRNPLAANh6uJ+CXyssjbUoe9EmyVxKX3l2zKmy1zOKRc/FbAkql07
ItDReryb64IjsfT4GtU4nBK7zCzI+yya1BjL/McnGBcpKIwp9HCwaTQK7yxa7ThY
TsfTuxoyZM1/xZE0cKRJGVLtkao1VfOy0SDdCp+RwtBvVmt3Wt6vVcL6qG0LW5Fe
Uz0PN+CebMfhBCaqWXIXeuMUo+RdLnGn113Tl6i6iwKCAQEAz+NzRUGMAXtDHF84
/OJWmD1BY3OH0TU9a8ztmPWbyGf6gA6laKcfAqS6nTIdTzbK1ZKZjES6gv65xHjb
ERFyj0BQ0pc/o7fcrHOVG8ofbvFdtMxB9lQvyB84+WBKqMDXyZMFZZyctBC75Rnp
no6BpKvmupM+LZZJyX/YksV6GcaX/j5I0sY63rMO8/n7XnogJNFczOHu5e0mo/uB
C8ItRKadER8NM+oOz3tOE3JQrvwrXyzAmngjPuAn5daA1qA7lhwcqMbQUi08D/HO
CCNW7BT+cXsTcHv2WpBYLLPGxOhWyF42e10p7R9YUfud9miGG+kfYGDfLtGOUA+E
0zEbFQKCAQEA4lczDnqolpv5394RkiG6+zXTdLYfaM2NUwTfZOka9xxEl8cJuztk
lAIoggjg1HcKB4EDSTA2vUVVlppjbEm9CZ70N7DRYcnWjr/hTgLOlNO4mp6Mxdny
qkwvR/fZLf8bzrs2qcRhIrM5DN/NA0Jn+10f+nMIQUTMSpgFxPDDBDe0SIlWTApV
TaLrTpIGLBfCe7+ef8O98qgPMEeW7vswXzQM2BVCqBZw+SUVyCOHlXukJZoPlKHI
AcThBNC/eQ3M3miG+YfNZ+yMls9q82viyM/WnN3GXzmCnE37XYb8dp0gZK1EQR8F
BF1fu6hXDLNkbhuZsiZMC92DvFPDYnkuNwKCAQA6/2K8PLlOeK+0p/IGVsgJpgHn
Uh3BehVKHXeG/Buhn5bMXX3cB2hEHg2tz4pw3JxfZ1UflhyhKD43XnpxuMmt81Ka
Ja5MeXDg0kfnlXolVA4ezx2V2EohMExUykkOIfQBDTaNtjsg5PB4HLKFId3kJ6u/
JCXuy0EA07vl/kNl+cDEBLJsVtvtxHLdpdJhO1POi3IIgOpddO+a/O/GDsdlAWog
hyEb6r7+bWurjw0YjHX+R5ZQ+0XtnzXU20d2NiP/oH2IvQzXRUQ1U17Kzzn5PAhs
YC7r9lRV4VjbhEi3Zk2FBPrrzs2ieXo5aHXCnzFywQ99nlrz0Ic8vV16WR1x
-----END RSA PRIVATE KEY-----
```

##### OAuth RSA-SHA256 Signature Generation

To prepare the Signature Base String do the following steps:

1. Gather all request body parameters and OAuth parameters (oauth_consumer_key, oauth_nonce, oauth_signature_method, oauth_timestamp, oauth_version):
 For oauth_consumer_key use a merchant login provided by Payment Gateway, ex. paydroid.
 
 For oauth_nonce generate unique random nonce, ex. ho Fl Zri9c17X1Tvb7yD2fsMEQUIWBQ3m.
 
 For oauth_signature_method set RSA-SHA256.
 
 For oauth_timestamp header get current timestamp in seconds, ex. 1669720957.
 
 For oauth_version set 1.0.
 
 Parameter oauth_signature is not included in request body parameters (only in OAuth header).
 
2. Percent-encode value of each gathered on step 1 parameter. See [RFC 3986](https://www.rfc-editor.org/rfc/rfc3986) for reference. The unreserved characters can be encoded, but should not be encoded. The reserved characters have to be encoded, for example: `%` is encoded to `%25`, `/` is encoded to `%2F`, `=` is encoded to `%3D`.
3. Sort all gathered on step 1 parameters together with their values in lexicographical order by parameter name.
4. Concatenate all gathered on step 1 parameters and their values using & and = by the following way: `object1=value Of Object1&object2=value Of Object2...`
 
5. Percent-encode each element (POST, URL, concatenated parameters) and construct Signature Base String with POST&URL&parameters structure (as documented in OAuth [A.5.1.](https://oauth.net/core/1.0a/#sig_base_example)).
 
 Signature Base String Example:
 
   ```text
   POST&https%3A%2F%2Fgate.payneteasy.eu%2Fpaynet%2Fapi%2Fv4%2Ftransfer%2FENDPOINTID&amount%3D10.42%26card_printed_name%3DJohn%2520Doe%26card_recurring_payment_id%3D42322%26client_orderid%3D1%26credit_card_number%3D4210708776705721%26currency%3DUSD%26cvv2%3D123%26deposit2card%3Dfalse%26destination-card-no%3D4232618181101636%26destination_card_recurring_payment_id%3D61622%26expire_month%3D12%26expire_year%3D2099%26ipaddress%3D1.1.1.1.1%26oauth_consumer_key%3Dpaydroid%26oauth_nonce%3DhoFlZri9c17X1Tvb7yD2fsMEQUIWBQ3m%26oauth_signature_method%3DRSA-SHA256%26oauth_timestamp%3D1669720957%26oauth_version%3D1.0%26order_desc%3DYour%2520order%2520description%26redirect_url%3Dhttp%253A%252F%252Fwww.example.com
   ```
6. Sign the Signature Base String with RSA-SHA256 using the private key obtained in previous section.
 
7. Base64 encode the signed string to get signature for API.
 
 Base64 Encoded Signature Example:
 
   ```text
   K0hLc7GYh65UDTNvJvJbqoD95T7ekVEwIx+AxLBe2rNndPVzCAZMTi58J5pJlXZA1qOrgzUj/uL764NofP6qrqBXHX9Fpg+PdoMBey7zY9nMOmtdpHhkwyqA0n8e8oh68x+8RtC1+gmaIsIJDVurpCm2CdaViC2ny90GWPrrSin9CFwDmIKBtOJ7dxNnuFQJkvLxwK9JE9gRfQssG4vOrXrn2f5DvENFvFW3fL7meiN3mKuBFyEHIv2cibWopoUTQrxAgCfTHvRuU5nRIct9oWgCYLYzROOPyAIjtyDFKcTnUql9+tD2+p2rMDDU7HqJUGy764rb4ShuvuiuEvzIaNwg3JAxho9fqcKJz5LXt4efX1i8oFt33ztYSgZRojsoW4HCzuhZcQQmRexpmtCGYKqH3Q2BsG2jIkQAxL9BOUOzXNoeXoVQIf3+47cJ0KujEHuDXROblq3o9Uos5K+Mu9Carjs8jHMiBHo4aS4IAgXVY3mEuohCuRhL9/Y9buuyvdKSNsao7qHwD/6bb9Sj2MFFhYP6gHf+p1NipH05224aX9hMZty8Ovb3+ps/wNWYC8NVfft5bh8ETowaHQ5TUOPFdvU+5IkHOnnfbvz1/+jDeErd0Pdq4xH6c5/gZVQY9j6DFpazsw8d3karwXoBduv7I3mh7L3CSjTweABaRMw=
   ```

##### OAuth RSA-SHA256 Headers Generation

A request with OAuth RSA-SHA256 authentication method must contain next headers:

* content-type=application/x-www-form-urlencoded
* Authorization: OAuth

OAuth header must contain the same OAuth parameters and values which were included in signature base string (oauth_consumer_key, oauth_nonce, oauth_signature_method, oauth_timestamp, oauth_version). Add signature as value of parameter oauth_signature to header Authorization. All values of parameters in OAuth header must be in quotes (See OAuth [5.4.1.](https://oauth.net/core/1.0a/#auth_header)) with the following structure: parameter=”value” and be separated by mandatory comma (,) and optional space. OAuth realm parameter is optional.
 
Authorization Header Example (Header is line-separated for display purposes):
 
```http
Authorization: OAuth
oauth_consumer_key="paydroid",
oauth_nonce="hoFlZri9c17X1Tvb7yD2fsMEQUIWBQ3m",
oauth_signature="K0hLc7GYh65UDTNvJvJbqoD95T7ekVEwIx%2BAxLBe2rNndPVzCAZMTi58J5pJlXZA1qOrgzUj%2FuL764NofP6qrqBXHX9Fpg%2BPdoMBey7zY9nMOmtdpHhkwyqA0n8e8oh68x%2B8RtC1%2BgmaIsIJDVurpCm2CdaViC2ny90GWPrrSin9CFwDmIKBtOJ7dxNnuFQJkvLxwK9JE9gRfQssG4vOrXrn2f5DvENFvFW3fL7meiN3mKuBFyEHIv2cibWopoUTQrxAgCfTHvRuU5nRIct9oWgCYLYzROOPyAIjtyDFKcTnUql9%2BtD2%2Bp2rMDDU7HqJUGy764rb4ShuvuiuEvzIaNwg3JAxho9fqcKJz5LXt4efX1i8oFt33ztYSgZRojsoW4HCzuhZcQQmRexpmtCGYKqH3Q2BsG2jIkQAxL9BOUOzXNoeXoVQIf3%2B47cJ0KujEHuDXROblq3o9Uos5K%2BMu9Carjs8jHMiBHo4aS4IAgXVY3mEuohCuRhL9%2FY9buuyvdKSNsao7qHwD%2F6bb9Sj2MFFhYP6gHf%2Bp1NipH05224aX9hMZty8Ovb3%2Bps%2FwNWYC8NVfft5bh8ETowaHQ5TUOPFdvU%2B5IkHOnnfbvz1%2F%2BjDeErd0Pdq4xH6c5%2FgZVQY9j6DFpazsw8d3karwXoBduv7I3mh7L3CSjTweABaRMw%3D",
oauth_signature_method="RSA-SHA256",
oauth_timestamp="1669720957",
oauth_version="1.0"
```

> **Note:** Since headers are not usually encoded, the values of oauth parameters (especially oauth_nonce and oauth_signature) should be percent-encoded separately before being added to Authorization header.

##### OAuth RSA-SHA256 Request Generation

To make the request:

1. Use headers from previous section,
2. Add request parameters to body,
3. Percent-encode and send the request.

Example of Request:

```text
Request method: POST
Request URI: https://gate.payneteasy.eu/paynet/api/v4/transfer/4473
Headers: Authorization= OAuth oauth_nonce="C12mCYiI4RDeVTvyZDHS3f0vUbBNrK9G", oauth_signature="S4ahUgep8EV3RTIPdcpO%2FzEwB8V1XwFcGi5zhrYKySPVVA2PAY7AxezPcOCMhMwZQfcf8VOH8O9v5zZ%2BmYV2Qsq4kjPe1zEJIjjdjhI%2B2MX9VW8dWn9DyoTD2lkOYUwGsCteXU6mwGtNergN5KwGTJgqYPfzWFLllSAhGwuOd%2FgHYVRnA6jd4FvywRaRiSsnzgsasGJjWCGzX%2F1B8L78H%2FqD1W7dNJHjC2JbonUiHVT4aOs74qpqYE9zcb5rK8PH1l2ems3ArXhqFaSF85%2BYzJ%2BkSeDswqeIZ1y3NS8XPrmaLeymLNqKpOfAl9Ng47AmIjSYEw3s5fQ7Xi9t4j7Y6fQA4RnIzIdmH4oeMiyzn7dpA87wqnXm5AIm6Den2TJaDg90UoCMXuGHkqfL8GGUSjaWleTOHlk%2FO4dBGDRw4LP1aEaJktQRmT5xwyoaQfz%2Bh2MR7zDpRbVZDpUto1iYlQl5UlgojOHaLLjW1gqggbvrtVXUBT73KcIboWW00VUcbVUX5Yb%2FSu7hUZO2fNAh4LYrsVcXRJxCZuwhXCiqvbR3EziEFDGVEZnKUDLCodzHbVA9hbpxHGa7TvSLFEANCPDFtapMF9eo%2F1yOt5Tkxag4g5yNes93lrVabsTqckiFIfKR2R3CcwJ6MQtMfo8ticJcKxfo2v%2BTkC0bEaRkBGk%3D", oauth_consumer_key="ny_qa_merchant", oauth_signature_method="RSA-SHA256", oauth_timestamp="1669892964", oauth_version="1.0"
         Accept=*/*
         Content-Type=application/x-www-form-urlencoded; charset=ISO-8859-1
Body: cvv2=123&ipaddress=1.1.1.1&amount=15.42&credit_card_number=4210708776705721&client_orderid=1&deposit2card=false&destination-card-no=4232618181101636&expire_month=12&order_desc=Your%20order%20description&card_printed_name=Vasia%20Pupkin&currency=RUB&expire_year=2099&redirect_url=http%3A%2F%2Fwww.example.com
```

Example of CURL Request:

```text
curl -H '
   Authorization: OAuth oauth_consumer_key="paydroid",
   oauth_nonce="JOARJWjXJgfRUVqig8HIs0ouFWKfK4N5",
   oauth_signature="k5Z0XCVdDvb5h873XG6TDMO854PsuueSnSby4h0%2F3j4TKraY6ebjoFfDmndI09%2FQp6uEbCgKregNY5N0ccIVIay49l6v7jMdIFEfqU7E5eu%2BIJcoqG7kMFcdCu29hweYx7p4ZSk%2FUtdGlN3wyUUybCAx73XYoO0tkZteAleyzQlzdpzQ99vPS8FN2WMbNdzU3H2PLf0XOZy4DbAPleZGfu3GWxXe9erGsvzBJozs3WFxiPFeULfzWWsNc1h1P7cnzNbZqXkI%2BV3qiG3jc7tDqGRZP%2BLZFw3nihNlW%2F2Nlp%2FId6QG8kPNOEx2GxAuQa8kufv%2BbpohU8UftZG1SnNfoa4nDVgNbWoSbTXbgXxwHE0ZlccwT6q%2BHbTmgggvIdGN9JuuLUL8fDSCxqu3R7YMvcwArzrkd1XEFUFvYWxHc3QpfbBu0GyLkL7pnmz%2BFPTH48COZ7yXbK6nQDFSIy8lmaEJsnnjMYyMMVgjNkDNzqwNxOQuwprTZ7KzHqWrTj0zHTOHl44q1pJhIqMwxWDPMsziExYbAzxuOkdQFZi%2BK%2Bu3M7tvG5Foy7Vwj%2BDSPMPAhj7j2AmUG4HzaJcpiBWMq0CkGWRjvneOk3NiwkEwOxq5tJOFjsroditUqJQSX1PTqf%2FtuiqaE2Gt5EYl19ZzyXbxtMjGZwL%2BzF1cT6ftTi4%3D",
   oauth_signature_method="RSA-SHA256",
   oauth_timestamp="1669892687",
   oauth_version="1.0"
' --data '
   amount=10.42
   &card_printed_name=John%20Doe
   &card_recurring_payment_id=42322
   &client_orderid=1
   &credit_card_number=4210708776705721
   &currency=USD
   &cvv2=123
   &deposit2card=false
   &destination-card-no=4232618181101636
   &destination_card_recurring_payment_id=61622
   &expire_month=12
   &expire_year=2099
   &ipaddress=1.1.1.1.1
   &order_desc=Your%20order%20description
   &redirect_url=http%3A%2F%2Fwww.example.com
' 'https://gate.payneteasy.eu/paynet/api/v4/transfer/ENDPOINTID'
```

##### OAuth RSA-SHA256 Integration example for Java

**Key points:**

1. Param sorting:
 : Request and OAuth parameters are merged and sorted alphabetically (Tree Map) before building the base string. The oauth_signature itself is excluded — it is added only after signing.
2. Percent-encoding:
 : Spaces must be %20, not +. Plain URLEncoder.encode produces +, so the helper post-processes the result.
3. Base string layout:
 : METHOD&percent Encode (url)&percent Encode (k1=v1&k2=v2&…) — each part is percent-encoded once, the inner & between params is encoded too.
4. Signature:
 : SHA256withRSA over the base string (UTF-8 bytes), Base64-encoded, then percent-encoded once more before being placed into the oauth_signature value.
5. Nonce/timestamp:
 : Fixed in this example for reproducibility against the docs. In production use generate Nonce() and Instant.now().get Epoch Second().
6. Private key:
 : PKCS#8 PEM (—–BEGIN PRIVATE KEY—–). PKCS#1 (—–BEGIN RSA PRIVATE KEY—–)\` is not consumed by Key Factory directly — convert it first: openssl pkcs8 -topk8 -nocrypt -in pkcs1.pem -out pkcs8.pem.

```text
import java.net.URLEncoder;
import java.nio.charset.StandardCharsets;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.security.KeyFactory;
import java.security.PrivateKey;
import java.security.SecureRandom;
import java.security.Signature;
import java.security.spec.PKCS8EncodedKeySpec;
import java.util.Base64;
import java.util.LinkedHashMap;
import java.util.Map;
import java.util.TreeMap;
import java.util.stream.Collectors;

public class PpgOAuthExample {

public static void main(String[] args) throws Exception {
        String url        = "https://hostname/paynet/api/v4/transfer/4473";
        String httpMethod = "POST";
        String privateKeyPemPath = "src/test/resources/private_key_pkcs_8.pem";

Map&lt;String, String&gt; request = new LinkedHashMap<>();
        request.put("amount",              "10.42");
        request.put("client_orderid",      "1");
        request.put("card_printed_name",   "John Doe");
        request.put("credit_card_number",  "4210708776705721");
        request.put("currency",            "USD");
        request.put("cvv2",                "123");
        request.put("deposit2card",        "false");
        request.put("destination-card-no", "4232618181101636");
        request.put("expire_month",        "12");
        request.put("expire_year",         "2099");
        request.put("ipaddress",           "1.1.1.1");
        request.put("order_desc",          "Your order description");
        request.put("redirect_url",        "http://www.example.com");

Map&lt;String, String&gt; oauth = new LinkedHashMap<>();
        oauth.put("oauth_consumer_key",     "ny_qa_merchant");
        oauth.put("oauth_nonce",            "es6l1gjUhxg1AeCrbvp9FILOkFmgtJUb"); // generateNonce()
        oauth.put("oauth_signature_method", "RSA-SHA256");
        oauth.put("oauth_timestamp",        "1668887494");                       // Instant.now().getEpochSecond()
        oauth.put("oauth_version",          "1.0");

String baseString = buildSignatureBaseString(httpMethod, url, request, oauth);
        String signature  = percentEncode(sign(baseString, loadPrivateKey(privateKeyPemPath)));
        oauth.put("oauth_signature", signature);

String authHeader = "OAuth " + oauth.entrySet().stream()
                .map(e -> e.getKey() + "=\"" + e.getValue() + "\"")
                .collect(Collectors.joining(", "));

String body = request.entrySet().stream()
                .map(e -> e.getKey() + "=" + percentEncode(e.getValue()))
                .collect(Collectors.joining("&"));

System.out.println("Authorization: " + authHeader);
        System.out.println();
        System.out.println("Content-Type: application/x-www-form-urlencoded");
        System.out.println();
        System.out.println(body);
    }

static String buildSignatureBaseString(String method, String url,
                                           Map&lt;String, String&gt; request,
                                           Map&lt;String, String&gt; oauth) {
        Map&lt;String, String&gt; merged = new TreeMap<>();
        merged.putAll(request);
        merged.putAll(oauth);
        String params = merged.entrySet().stream()
                .map(e -> percentEncode(e.getKey()) + "=" + percentEncode(e.getValue()))
                .collect(Collectors.joining("&"));
        return percentEncode(method) + "&" + percentEncode(url) + "&" + percentEncode(params);
    }

// OAuth percent-encoding: like URLEncoder but space is %20, not '+'.
    static String percentEncode(String s) {
        try {
            return URLEncoder.encode(s, StandardCharsets.UTF_8.name()).replace("+", "%20");
        } catch (Exception e) {
            throw new RuntimeException(e);
        }
    }

static String sign(String input, PrivateKey key) throws Exception {
        Signature sig = Signature.getInstance("SHA256withRSA");
        sig.initSign(key);
        sig.update(input.getBytes(StandardCharsets.UTF_8));
        return Base64.getEncoder().encodeToString(sig.sign());
    }

static PrivateKey loadPrivateKey(String pemPath) throws Exception {
        String pem = new String(Files.readAllBytes(Paths.get(pemPath)), StandardCharsets.UTF_8)
                .replace("-----BEGIN PRIVATE KEY-----", "")
                .replace("-----END PRIVATE KEY-----", "")
                .replaceAll("\\s", "");
        byte[] der = Base64.getDecoder().decode(pem);
        return KeyFactory.getInstance("RSA").generatePrivate(new PKCS8EncodedKeySpec(der));
    }

static String generateNonce() {
        char[] alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789".toCharArray();
        SecureRandom rnd = new SecureRandom();
        StringBuilder sb = new StringBuilder(32);
        for (int i = 0; i < 32; i++) sb.append(alphabet[rnd.nextInt(alphabet.length)]);
        return sb.toString();
    }
}
```

##### OAuth RSA-SHA256 Integration example for PHP

```text
<?php
/**
 * OAuth RSA-SHA256 Integration Example for gate.payneteasy.eu API
 * This example demonstrates a simplified single-file implementation
 */

// Include the OAuth library (tmhOAuth)
class tmhOAuth {
  const VERSION = '0.8.5';
  var $response = array();

  /**
   * Creates a new tmhOAuth object
   *
   * @param string $config, the configuration to use for this request
   * @return void
   */
  public function __construct($config=array()) {
    $this->buffer = null;
    $this->reconfigure($config);
    $this->reset_request_settings();
    $this->set_user_agent();
  }

  public function reconfigure($config=array()) {
    // default configuration options
    $this->config = array_merge(
      array(
        // leave 'user_agent' blank for default, otherwise set this to
        // something that clearly identifies your app
        'user_agent'                 => '',
        'host'                       => 'api.twitter.com',
        'method'                     => 'GET',

        'consumer_key'               => '',
        'consumer_secret'            => '',
        'token'                      => '',
        'secret'                     => '',

        // RSA private key (for RSA-SHA1 and RSA-SHA256 methods)
        // Please note that this is expected to be a string representing
        // the PEM-formatted key itself and NOT the file name
        'private_key_pem'            => '',

        // OAuth2 bearer token. This should already be URL encoded
        'bearer'                     => '',

        // oauth signing variables that are not dynamic
        'oauth_version'              => '1.0',
        'oauth_signature_method'     => 'HMAC-SHA1',

        // you probably don't want to change any of these curl values
        'curl_http_version'          => CURL_HTTP_VERSION_1_1,
        'curl_connecttimeout'        => 30,
        'curl_timeout'               => 10,

        // for security this should always be set to 2.
        'curl_ssl_verifyhost'        => 2,
        // for security this should always be set to true.
        'curl_ssl_verifypeer'        => true,
        // for security this should always be set to true.
        'use_ssl'                    => true,

        // you can get the latest cacert.pem from here http://curl.haxx.se/ca/cacert.pem
        // if you're getting HTTP 0 responses, check cacert.pem exists and is readable
        // without it curl won't be able to create an SSL connection
        'curl_cainfo'                => __DIR__ . DIRECTORY_SEPARATOR . 'cacert.pem',
        'curl_capath'                => __DIR__,

        // in some cases (very very odd ones) the SSL version must be set manually.
        // unless you know why your are changing this, you should leave it as false
        // to allow PHP to determine the value for this setting itself.
        'curl_sslversion'            => false,

        'curl_followlocation'        => false, // whether to follow redirects or not

        // support for proxy servers
        'curl_proxy'                 => false, // really you don't want to use this if you are using streaming
        'curl_proxyuserpwd'          => false, // format username:password for proxy, if required
        'curl_encoding'              => '',    // leave blank for all supported formats, else use gzip, deflate, identity etc

        // streaming API configuration
        'is_streaming'               => false,
        'streaming_eol'              => "\r\n",
        'streaming_metrics_interval' => 10,

        // header or querystring. You should always use header!
        // this is just to help me debug other developers implementations
        'as_header'                  => true,
        'force_nonce'                => false, // used for checking signatures. leave as false for auto
        'force_timestamp'            => false, // used for checking signatures. leave as false for auto
      ),
      $config
    );
  }

  private function reset_request_settings($options=array()) {
    $this->request_settings = array(
      'params'    => array(),
      'headers'   => array(),
      'with_user' => true,
      'multipart' => false,
    );

    if (!empty($options))
      $this->request_settings = array_merge($this->request_settings, $options);
  }

  /**
   * Sets the useragent for PHP to use
   * If '$this->config['user_agent']' already has a value it is used instead of one
   * being generated.
   *
   * @return void value is stored to the config array class variable
   */
  private function set_user_agent() {
    if (!empty($this->config['user_agent']))
      return;

    $ssl = ($this->config['curl_ssl_verifyhost'] && $this->config['curl_ssl_verifypeer'] && $this->config['use_ssl']) ? '+' : '-';
    $ua = 'tmhOAuth ' . self::VERSION . $ssl . 'SSL - //github.com/themattharris/tmhOAuth';
    $this->config['user_agent'] = $ua;
  }

  /**
   * Generates a random OAuth nonce.
   * If 'force_nonce' is false a nonce will be generated, otherwise the value of '$this->config['force_nonce']' will be used.
   *
   * @param string $length how many characters the nonce should be before MD5 hashing. default 12
   * @param string $include_time whether to include time at the beginning of the nonce. default true
   * @return $nonce as a string
   */
  private function nonce($length=12, $include_time=true) {
    if ($this->config['force_nonce'] === false) {
      $prefix = $include_time ? microtime() : '';
      return md5(substr($prefix . uniqid(), 0, $length));
    } else {
      return $this->config['force_nonce'];
    }
  }

  /**
   * Generates a timestamp.
   * If 'force_timestamp' is false a timestamp will be generated, otherwise the value of '$this->config['force_timestamp']' will be used.
   *
   * @return $time as a string
   */
  private function timestamp() {
    if ($this->config['force_timestamp'] === false) {
      $time = time();
    } else {
      $time = $this->config['force_timestamp'];
    }
    return (string) $time;
  }

  /**
   * Encodes the string or array passed in a way compatible with OAuth.
   * If an array is passed each array value will will be encoded.
   *
   * @param mixed $data the scalar or array to encode
   * @return $data encoded in a way compatible with OAuth
   */
  private function safe_encode($data) {
    if (is_array($data)) {
      return array_map(array($this, 'safe_encode'), $data);
    } else if (is_scalar($data)) {
      return str_ireplace(
        array('+', '%7E'),
        array(' ', '~'),
        rawurlencode($data)
      );
    } else {
      return '';
    }
  }

  /**
   * Decodes the string or array from it's URL encoded form
   * If an array is passed each array value will will be decoded.
   *
   * @param mixed $data the scalar or array to decode
   * @return string $data decoded from the URL encoded form
   */
  private function safe_decode($data) {
    if (is_array($data)) {
      return array_map(array($this, 'safe_decode'), $data);
    } else if (is_scalar($data)) {
      return rawurldecode($data);
    } else {
      return '';
    }
  }

  /**
   * Prepares OAuth1 signing parameters.
   *
   * @return void all required OAuth parameters, safely encoded, are stored to the class variable '$this->request_settings['oauth1_params']'
   */
  private function prepare_oauth1_params() {
    $defaults = array(
      'oauth_nonce'            => $this->nonce(),
      'oauth_timestamp'        => $this->timestamp(),
      'oauth_version'          => $this->config['oauth_version'],
      'oauth_consumer_key'     => $this->config['consumer_key'],
      'oauth_signature_method' => $this->config['oauth_signature_method'],
    );

    // include the user token if it exists
    if ( $oauth_token = $this->token() )
      $defaults['oauth_token'] = $oauth_token;

    $this->request_settings['oauth1_params'] = array();

    // safely encode
    foreach ($defaults as $k => $v) {
      $this->request_settings['oauth1_params'][$this->safe_encode($k)] = $this->safe_encode($v);
    }
  }

  private function token() {
    if ( $this->request_settings['with_user'] ) {
      if (isset($this->config['token']) && !empty($this->config['token'])) return $this->config['token'];
      elseif (isset($this->config['user_token'])) return $this->config['user_token'];
    }
    return '';
  }

  private function secret() {
    if ( $this->request_settings['with_user'] ) {
      if (isset($this->config['secret']) && !empty($this->config['secret'])) return $this->config['secret'];
      elseif (isset($this->config['user_secret'])) return $this->config['user_secret'];
    }
    return '';
  }

  /**
   * Extracts and decodes OAuth parameters from the passed string
   *
   * @param string $body the response body from an OAuth flow method
   * @return array the response body safely decoded to an array of key => values
   */
  public function extract_params($body) {
    $kvs = explode('&', $body);
    $decoded = array();
    foreach ($kvs as $kv) {
      $kv = explode('=', $kv, 2);
      $kv[0] = $this->safe_decode($kv[0]);
      $kv[1] = $this->safe_decode($kv[1]);
      $decoded[$kv[0]] = $kv[1];
    }
    return $decoded;
  }

  /**
   * Prepares the HTTP method for use in the base string by converting it to
   * uppercase.
   *
   * @return void value is stored to the class variable '$this->request_settings['method']'
   */
  private function prepare_method() {
    $this->request_settings['method'] = strtoupper($this->request_settings['method']);
  }

  /**
   * Prepares the URL for use in the base string by ripping it apart and
   * reconstructing it.
   *
   * Ref: 3.4.1.2
   *
   * @return void value is stored to the class array variable '$this->request_settings['url']'
   */
  private function prepare_url() {
    $parts = parse_url($this->request_settings['url']);

    $port   = isset($parts['port']) ? $parts['port'] : false;
    $scheme = $parts['scheme'];
    $host   = $parts['host'];
    $path   = isset($parts['path']) ? $parts['path'] : false;

    $port or $port = ($scheme == 'https') ? '443' : '80';

    if (($scheme == 'https' && $port != '443') || ($scheme == 'http' && $port != '80')) {
      $host = "$host:$port";
    }

    // the scheme and host MUST be lowercase
    $this->request_settings['url'] = strtolower("$scheme://$host");
    // but not the path
    $this->request_settings['url'] .= $path;
  }

  /**
   * If the request uses multipart, and the parameter isn't a file path, prepend a space
   * otherwise return the original value. we chose a space here as twitter whitespace trims from
   * the beginning of the tweet. we don't use \0 here because it's the character for string
   * termination.
   *
   * @param the parameter value
   * @return string the original or modified string, depending on the request and the input parameter
   */
  private function multipart_escape($value) {
    if (!$this->request_settings['multipart'] || strpos($value, '@') !== 0)
      return $value;

    // see if the parameter is a file.
    // we split on the semi-colon as it's the delimiter used on media uploads
    // for fields with semi-colons this will return the original string
    list($file) = explode(';', substr($value, 1), 2);
    if (file_exists($file))
      return $value;

    return " $value";
  }

  /**
   * Prepares all parameters for the base string and request.
   * Multipart parameters are ignored as they are not defined in the specification,
   * all other types of parameter are encoded for compatibility with OAuth.
   *
   * @param array $params the parameters for the request
   * @return void prepared values are stored in the class array variable '$this->request_settings'
   */
  private function prepare_params() {
    $doing_oauth1 = false;
    $this->request_settings['prepared_params'] = array();
    $prepared = &$this->request_settings['prepared_params'];
    $prepared_pairs = array();
    $prepared_pairs_with_oauth = array();

    if (isset($this->request_settings['oauth1_params'])) {
      $oauth1  = &$this->request_settings['oauth1_params'];
      $doing_oauth1 = true;
      $params = array_merge($oauth1, $this->request_settings['params']);

      // Remove oauth_signature if present
      // Ref: Spec: 9.1.1 ("The oauth_signature parameter MUST be excluded.")
      unset($params['oauth_signature']);

      // empty the oauth1 array. we reset these values later in this method
      $oauth1 = array();
    } else {
      $params = $this->request_settings['params'];
    }

    // Parameters are sorted by name, using lexicographical byte value ordering.
    // Ref: Spec: 9.1.1 (1)
    uksort($params, 'strcmp');

    // set this now so we're not doing it on every parameter
    $supports_curl_file = class_exists('CurlFile', false);

    // encode params unless we're doing multipart
    foreach ($params as $k => $v) {
      $k = $this->request_settings['multipart'] ? $k : $this->safe_encode($k);

      if (is_array($v))
        $v = implode(',', $v);

      // we don't need to do the multipart escaping if we support curlfile
      if ($supports_curl_file && ($v instanceof CurlFile)) {
        // leave $v alone
      } elseif ($this->request_settings['multipart']) {
        $v = $this->multipart_escape($v);
      } else {
        $v = $this->safe_encode($v);
      }

      // split parameters for the basestring and authorization header, and recreate the oauth1 array
      if ($doing_oauth1) {
        // if we're doing multipart, only store the oauth_* params, ignore the users request params
        if ((strpos($k, 'oauth') === 0) || !$this->request_settings['multipart'])
          $prepared_pairs_with_oauth[] = "{$k}={$v}";

        if (strpos($k, 'oauth') === 0) {
          $oauth1[$k] = $v;
          continue;
        }
      }
      $prepared[$k] = $v;

      if (!$this->request_settings['multipart'])
        $prepared_pairs[] = "{$k}={$v}";
    }

    if ($doing_oauth1) {
      $this->request_settings['basestring_params'] = implode('&', $prepared_pairs_with_oauth);
    }

    // setup params for GET/POST/PUT method handling
    if (!empty($prepared)) {
      $content = implode('&', $prepared_pairs);

      switch ($this->request_settings['method']) {
        case 'PUT':
          // fall through to POST as PUT should be treated the same
        case 'POST':
          $this->request_settings['postfields'] = $this->request_settings['multipart'] ? $prepared : $content;
          break;
        default:
          $this->request_settings['querystring'] = $content;
          break;
      }
    }
  }

  /**
   * Prepares the OAuth signing key
   *
   * @return void prepared signing key is stored in the class variable 'signing_key'
   */
  private function prepare_signing_key() {
    $left = $this->safe_encode($this->config['consumer_secret']);
    $right = $this->safe_encode($this->secret());
    $this->request_settings['signing_key'] = $left . '&' . $right;
  }

  /**
   * Prepare the base string.
   * Ref: Spec: 9.1.3 ("Concatenate Request Elements")
   *
   * @return void prepared base string is stored in the class variable 'base_string'
   */
  private function prepare_base_string() {
    $url = $this->request_settings['url'];

    # if the host header is set we need to rewrite the basestring to use
    # that, instead of the request host. otherwise the signature won't match
    # on the server side
    if (!empty($this->request_settings['headers']['Host'])) {
      $url = str_ireplace(
        $this->config['host'],
        $this->request_settings['headers']['Host'],
        $url
      );
    }

    $base = array(
      $this->request_settings['method'],
      $url,
      $this->request_settings['basestring_params']
    );
    $this->request_settings['basestring'] = implode('&', $this->safe_encode($base));
  }

  /**
   * Signs the OAuth 1 request
   *
   * @return void oauth_signature is added to the parameters in the class array variable '$this->request_settings'
   */
  private function prepare_oauth_signature() {
    switch ($this->config['oauth_signature_method']) {
      case 'HMAC-SHA1':
        $signature = $this->sign_with_hmac('sha1');
        break;
      case 'HMAC-SHA256':
        $signature = $this->sign_with_hmac('sha256');
        break;
      case 'RSA-SHA1':
        $signature = $this->sign_with_rsa(OPENSSL_ALGO_SHA1);
        break;
      case 'RSA-SHA256':
        $signature = $this->sign_with_rsa(OPENSSL_ALGO_SHA256);
        break;
      default:
        throw new Exception("Unsupported oauth_signature_method: '" . $this->config['oauth_signature_method'] . "'");
    }
    $this->request_settings['oauth1_params']['oauth_signature'] = $this->safe_encode(base64_encode($signature));
  }

  /**
   * Signs the OAuth 1 request using HMAC-based signature algorithm
   *
   * @param string $algorithm algorithm name (like sha1 or sha256)
   * @return binary signature
   */
  private function sign_with_hmac($algorithm) {
    return hash_hmac(
      $algorithm, $this->request_settings['basestring'], $this->request_settings['signing_key'], true
    );
  }

  /**
   * Signs the OAuth 1 request using RSA-based signature algorithm
   *
   * @param mixed $algorithm ID or name of hash algorithm that will be
   * used to compute base string hash before encrypting it with RSA;
   * values understood by openssl_sign()'s $signature_alg parameter
   * are accepted here (like 'sha1' or OPENSSL_ALGO_SHA256)
   * @return binary signature
   */
  private function sign_with_rsa($algorithm) {
    if (!function_exists('openssl_sign')) {
      throw new Exception("openssl_sign function does not exist. Please make sure Openssl extension is installed");
    }
    if ($this->config['private_key_pem'] == '') {
      throw new Exception("No private key PEM is configured, cannot sign");
    }
    $ok = openssl_sign($this->request_settings['basestring'], $signature, $this->config['private_key_pem'], $algorithm);
    if (!$ok) {
      throw new Exception("Cannot sign: " . openssl_error_string());
    }
    return $signature;
  }

  /**
   * Prepares the Authorization header
   *
   * @return void prepared authorization header is stored in the class variable headers['Authorization']
   */
  private function prepare_auth_header() {
    if (!$this->config['as_header'])
      return;

    // oauth1
    if (isset($this->request_settings['oauth1_params'])) {
      // sort again as oauth_signature was added post param preparation
      uksort($this->request_settings['oauth1_params'], 'strcmp');
      $encoded_quoted_pairs = array();
      foreach ($this->request_settings['oauth1_params'] as $k => $v) {
        $encoded_quoted_pairs[] = "{$k}=\"{$v}\"";
      }
      $header = 'OAuth ' . implode(', ', $encoded_quoted_pairs);
    } elseif (!empty($this->config['bearer'])) {
      $header = 'Bearer ' . $this->config['bearer'];
    }

    if (isset($header))
      $this->request_settings['headers']['Authorization'] = $header;
  }

  /**
   * Create the bearer token for OAuth2 requests from the consumer_key and consumer_secret.
   *
   * @return string the bearer token
   */
  public function bearer_token_credentials() {
    $credentials = implode(':', array(
      $this->safe_encode($this->config['consumer_key']),
      $this->safe_encode($this->config['consumer_secret'])
    ));
    return base64_encode($credentials);
  }

  /**
   * Make an HTTP request using this library. This method doesn't return anything.
   * Instead the response should be inspected directly.
   *
   * @param string $method the HTTP method being used. e.g. POST, GET, HEAD etc
   * @param string $url the request URL without query string parameters
   * @param array $params the request parameters as an array of key=value pairs. Default empty array
   * @param string $useauth whether to use authentication when making the request. Default true
   * @param string $multipart whether this request contains multipart data. Default false
   * @param array $headers any custom headers to send with the request. Default empty array
   * @return int the http response code for the request. 0 is returned if a connection could not be made
   */
  public function request($method, $url, $params=array(), $useauth=true, $multipart=false, $headers=array()) {
    $options = array(
      'method'    => $method,
      'url'       => $url,
      'params'    => $params,
      'with_user' => true,
      'multipart' => $multipart,
      'headers'   => $headers
    );
    $options = array_merge($this->default_options(), $options);

    if ($useauth) {
      return $this->user_request($options);
    } else {
      return $this->unauthenticated_request($options);
    }
  }

  public function apponly_request($options=array()) {
    $options = array_merge($this->default_options(), $options, array(
      'with_user' => false,
    ));
    $this->reset_request_settings($options);
    if ($options['without_bearer']) {
      return $this->oauth1_request();
    } else {
      $this->prepare_method();
      $this->prepare_url();
      $this->prepare_params();
      $this->prepare_auth_header();
      return $this->curlit();
    }
  }

  public function user_request($options=array()) {
    $options = array_merge($this->default_options(), $options, array(
      'with_user' => true,
    ));
    $this->reset_request_settings($options);
    return $this->oauth1_request();
  }

  public function unauthenticated_request($options=array()) {
    $options = array_merge($this->default_options(), $options, array(
      'with_user' => false,
    ));
    $this->reset_request_settings($options);
    $this->prepare_method();
    $this->prepare_url();
    $this->prepare_params();
    return $this->curlit();
  }

  /**
   * Signs the request and adds the OAuth signature. This runs all the request
   * parameter preparation methods.
   *
   * @param string $method the HTTP method being used. e.g. POST, GET, HEAD etc
   * @param string $url the request URL without query string parameters
   * @param array $params the request parameters as an array of key=value pairs
   * @param boolean $with_user whether to include the user credentials when making the request.
   * @return void
   */
  private function oauth1_request() {
    $this->prepare_oauth1_params();
    $this->prepare_method();
    $this->prepare_url();
    $this->prepare_params();
    $this->prepare_base_string();
    $this->prepare_signing_key();
    $this->prepare_oauth_signature();
    $this->prepare_auth_header();
    return $this->curlit();
  }

  private function default_options() {
    return array(
      'method'         => 'GET',
      'params'         => array(),
      'with_user'      => true,
      'multipart'      => false,
      'headers'        => array(),
      'without_bearer' => false,
    );
  }

  /**
   * Make a long poll HTTP request using this library. This method is
   * different to the other request methods as it isn't supposed to disconnect
   *
   * Using this method expects a callback which will receive the streaming
   * responses.
   *
   * @param string $method the HTTP method being used. e.g. POST, GET, HEAD etc
   * @param string $url the request URL without query string parameters
   * @param array $params the request parameters as an array of key=value pairs
   * @param string $callback the callback function to stream the buffer to.
   * @return void
   */
  public function streaming_request($method, $url, $params=array(), $callback='') {
    if ( ! empty($callback) ) {
      if ( ! is_callable($callback) ) {
        return false;
      }
      $this->config['streaming_callback'] = $callback;
    }
    $this->metrics['start']          = time();
    $this->metrics['interval_start'] = $this->metrics['start'];
    $this->metrics['messages']       = 0;
    $this->metrics['last_messages']  = 0;
    $this->metrics['bytes']          = 0;
    $this->metrics['last_bytes']     = 0;
    $this->config['is_streaming']    = true;
    $this->request($method, $url, $params);
  }

  /**
   * Handles the updating of the current Streaming API metrics.
   *
   * @return array the metrics for the streaming api connection
   */
  private function update_metrics() {
    $now = time();
    if (($this->metrics['interval_start'] + $this->config['streaming_metrics_interval']) > $now)
      return null;

    $this->metrics['mps'] = round( ($this->metrics['messages'] - $this->metrics['last_messages']) / $this->config['streaming_metrics_interval'], 2);
    $this->metrics['bps'] = round( ($this->metrics['bytes'] - $this->metrics['last_bytes']) / $this->config['streaming_metrics_interval'], 2);

    $this->metrics['last_bytes'] = $this->metrics['bytes'];
    $this->metrics['last_messages'] = $this->metrics['messages'];
    $this->metrics['interval_start'] = $now;
    return $this->metrics;
  }

  /**
   * Utility function to create the request URL in the requested format.
   * If a fully-qualified URI is provided, it will be returned.
   * Any multi-slashes (except for the protocol) will be replaced with a single slash.
   *
   *
   * @param string $request the API method without extension
   * @param string $extension the format of the response. Default json. Set to an empty string to exclude the format
   * @return string the concatenation of the host, API version, API method and format, or $request if it begins with http
   */
  public function url($request, $extension='json') {
    // remove multi-slashes
    $request = preg_replace('$([^:])//+$', '$1/', $request);

    if (stripos($request, 'http') === 0 || stripos($request, '//') === 0) {
      return $request;
    }

    $extension = strlen($extension) > 0 ? ".$extension" : '';
    $proto  = $this->config['use_ssl'] ? 'https:/' : 'http:/';

    // trim trailing slash
    $request = ltrim($request, '/');

    $pos = strlen($request) - strlen($extension);
    if (substr($request, $pos) === $extension)
      $request = substr_replace($request, '', $pos);

    return implode('/', array(
      $proto,
      $this->config['host'],
      $request . $extension
    ));
  }

  /**
   * Public access to the private safe decode/encode methods
   *
   * @param string $text the text to transform
   * @param string $mode the transformation mode. either encode or decode
   * @return string $text transformed by the given $mode
   */
  public function transformText($text, $mode='encode') {
    return $this->{"safe_$mode"}($text);
  }

  /**
   * Utility function to parse the returned curl headers and store them in the
   * class array variable.
   *
   * @param object $ch curl handle
   * @param string $header the response headers
   * @return string the length of the header
   */
  private function curlHeader($ch, $header) {
    $this->response['raw'] .= $header;

    list($key, $value) = array_pad(explode(':', $header, 2), 2, null);

    $key = trim($key);
    $value = trim($value);

    if ( ! isset($this->response['headers'][$key])) {
      $this->response['headers'][$key] = $value;
    } else {
      if (!is_array($this->response['headers'][$key])) {
        $this->response['headers'][$key] = array($this->response['headers'][$key]);
      }
      $this->response['headers'][$key][] = $value;
    }

    return strlen($header);
  }

  /**
    * Utility function to parse the returned curl buffer and store them until
    * an EOL is found. The buffer for curl is an undefined size so we need
    * to collect the content until an EOL is found.
    *
    * This function calls the previously defined streaming callback method.
    *
    * @param object $ch curl handle
    * @param string $data the current curl buffer
    * @return int the length of the data string processed in this function
    */
  private function curlWrite($ch, $data) {
    $l = strlen($data);
    if (strpos($data, $this->config['streaming_eol']) === false) {
      $this->buffer .= $data;
      return $l;
    }

    $buffered = explode($this->config['streaming_eol'], $data);
    $content = $this->buffer . $buffered[0];

    $this->metrics['messages']++;
    $this->metrics['bytes'] += strlen($content);

    if ( ! is_callable($this->config['streaming_callback']))
      return 0;

    $metrics = $this->update_metrics();
    $stop = call_user_func(
      $this->config['streaming_callback'],
      $content,
      strlen($content),
      $metrics
    );
    $this->buffer = $buffered[1];
    if ($stop)
      return 0;

    return $l;
  }

  /**
   * Makes a curl request. Takes no parameters as all should have been prepared
   * by the request method
   *
   * the response data is stored in the class variable 'response'
   *
   * @return int the http response code for the request. 0 is returned if a connection could not be made
   */
  private function curlit() {
    $this->response = array(
      'raw' => ''
    );

    // configure curl
    $c = curl_init();

    if ($this->request_settings['method'] == 'GET' && isset($this->request_settings['querystring'])) {
      $this->request_settings['url'] = $this->request_settings['url'] . '?' . $this->request_settings['querystring'];
    } elseif ($this->request_settings['method'] == 'POST' || $this->request_settings['method'] == 'PUT') {
      $postfields = array();
      if (isset($this->request_settings['postfields']))
        $postfields = $this->request_settings['postfields'];

      curl_setopt($c, CURLOPT_POSTFIELDS, $postfields);
    }

    curl_setopt($c, CURLOPT_CUSTOMREQUEST, $this->request_settings['method']);

    curl_setopt_array($c, array(
      CURLOPT_HTTP_VERSION   => $this->config['curl_http_version'],
      CURLOPT_USERAGENT      => $this->config['user_agent'],
      CURLOPT_CONNECTTIMEOUT => $this->config['curl_connecttimeout'],
      CURLOPT_TIMEOUT        => $this->config['curl_timeout'],
      CURLOPT_RETURNTRANSFER => true,
      CURLOPT_SSL_VERIFYPEER => $this->config['curl_ssl_verifypeer'],
      CURLOPT_SSL_VERIFYHOST => $this->config['curl_ssl_verifyhost'],

      CURLOPT_FOLLOWLOCATION => $this->config['curl_followlocation'],
      CURLOPT_PROXY          => $this->config['curl_proxy'],
      CURLOPT_ENCODING       => $this->config['curl_encoding'],
      CURLOPT_URL            => $this->request_settings['url'],
      // process the headers
      CURLOPT_HEADERFUNCTION => array($this, 'curlHeader'),
      CURLOPT_HEADER         => false,
      CURLINFO_HEADER_OUT    => true,
    ));

    if ($this->config['curl_cainfo'] !== false)
      curl_setopt($c, CURLOPT_CAINFO, $this->config['curl_cainfo']);

    if ($this->config['curl_capath'] !== false)
      curl_setopt($c, CURLOPT_CAPATH, $this->config['curl_capath']);

    if ($this->config['curl_proxyuserpwd'] !== false)
      curl_setopt($c, CURLOPT_PROXYUSERPWD, $this->config['curl_proxyuserpwd']);

    if ($this->config['curl_sslversion'] !== false)
      curl_setopt($c, CURLOPT_SSLVERSION, $this->config['curl_sslversion']);

    if ($this->config['is_streaming']) {
      // process the body
      $this->response['content-length'] = 0;
      curl_setopt($c, CURLOPT_TIMEOUT, 0);
      curl_setopt($c, CURLOPT_WRITEFUNCTION, array($this, 'curlWrite'));
    }

    if ( ! empty($this->request_settings['headers'])) {
      foreach ($this->request_settings['headers'] as $k => $v) {
        $headers[] = trim($k . ': ' . $v);
      }
      curl_setopt($c, CURLOPT_HTTPHEADER, $headers);
    }

    if (isset($this->config['block']) && (true === $this->config['block']))
      return 0;

    // do it!
    $response = curl_exec($c);
    $code = curl_getinfo($c, CURLINFO_HTTP_CODE);
    $info = curl_getinfo($c);
    $error = curl_error($c);
    $errno = curl_errno($c);
    curl_close($c);

    // store the response
    $this->response['code'] = $code;
    $this->response['response'] = $response;
    $this->response['info'] = $info;
    $this->response['error'] = $error;
    $this->response['errno'] = $errno;

    if (!isset($this->response['raw'])) {
      $this->response['raw'] = '';
    }
    $this->response['raw'] .= $response;

    return $code;
  }
}

/*
 * Configuration - Replace these values with your actual credentials
 */
$config = [
    'server_host' => 'sandbox.payneteasy.eu',
    'endpoint_id' => 1, // Your endpoint ID
    'merchant_login' => 'your-merchant-login',
    'private_key_file' => 'test-private-key.pem', // Your private key file
    'test_mode' => true // Set to false for production
];

/*
 * API Request Function
 */
function makeApiRequest($endpoint, $params, $config) {
    // Load private key
    $private_key_pem = file_get_contents($config['private_key_file']);
    if (!$private_key_pem) {
        throw new Exception("Could not load private key file");
    }

    // Initialize OAuth
    $oauth = new tmhOAuth();
    $oauth->reconfigure([
        'consumer_key' => $config['merchant_login'],
        'oauth_signature_method' => 'RSA-SHA256',
        'private_key_pem' => $private_key_pem,
        'curl_ssl_verifypeer' => $config['test_mode'] ? false : true
    ]);

    // Make request
    $url = "https://{$config['server_host']}/paynet/api/v4/{$endpoint}/{$config['endpoint_id']}";
    $status = $oauth->request('POST', $url, $params);

    // Handle response
    if ($status == 0) {
        throw new Exception('HTTP request failed');
    } elseif ($status != 200) {
        throw new Exception("HTTP error: {$status}");
    }

    return [
        'status' => $status,
        'response' => $oauth->response['response'],
        'headers' => $oauth->response['headers']
    ];
}

/*
 * Example Usage - Transfer by Reference
 */
if (isset($_POST['action']) && $_POST['action'] == 'transfer') {
    try {
        $params = [
            'client-order-id' => 'transfer-' . uniqid(),
            'amount' => $_POST['amount'] ?? '100',
            'currency' => $_POST['currency'] ?? 'RUB',
            'order_desc' => $_POST['description'] ?? 'Consumer credit',
            'destination-card-no' => $_POST['card_number'] ?? '4444333322221111'
        ];

        $result = makeApiRequest('transfer-by-ref', $params, $config);
        $response = json_decode($result['response'], true);

        echo "<div class='alert alert-success'>Success! Transaction ID: " .
             ($response['transaction-id'] ?? 'N/A') . "</div>";

    } catch (Exception $e) {
        echo "<div class='alert alert-danger'>Error: " . $e->getMessage() . "</div>";
    }
}

/*
 * Example Usage - Bank Payout
 */
if (isset($_POST['action']) && $_POST['action'] == 'payout') {
    try {
        $params = [
            'client-order-id' => 'payout-' . uniqid(),
            'amount' => $_POST['amount'] ?? '100',
            'currency' => $_POST['currency'] ?? 'USD',
            'order_desc' => $_POST['description'] ?? 'Bank payout',
            'account_number' => $_POST['account_number'] ?? '123412341234',
            'bank_name' => $_POST['bank_name'] ?? 'Test Bank'
        ];

        $result = makeApiRequest('payout', $params, $config);
        $response = json_decode($result['response'], true);

        echo "<div class='alert alert-success'>Success! Payout ID: " .
             ($response['payout-id'] ?? 'N/A') . "</div>";

    } catch (Exception $e) {
        echo "<div class='alert alert-danger'>Error: " . $e->getMessage() . "</div>";
    }
}
?>
```

### OpenAPI Specification

The API is described by a machine-readable specification in OpenAPI 3.1
format. The full JSON schema is published at
[https://doc.payneteasy.com/openapi.json](https://doc.payneteasy.com/openapi.json).

You can use it to:

- browse the API interactively in your browser
- generate client SDKs in your language of choice
- import the API into tools such as Postman or Insomnia
- feed it to AI coding assistants to generate clients and integrations

#### Response Format

By default the gateway returns responses in
`application/x-www-form-urlencoded` format — the same as it always
has. This behaviour is unchanged: when you send no special `Accept`
header, you keep receiving form-encoded responses exactly as before.

To receive the same data as JSON instead, send the
`Accept: application/vnd.pay+json` request header. A JSON response is
easier to deserialize, especially when you parse the response by hand.

This affects the **response** only — the **request** body is still sent
as `application/x-www-form-urlencoded` in both cases, with or without
the header.

Default response (`application/x-www-form-urlencoded`):

```text
type=async-response
&serial-number=00000000-0000-0000-0000-000002d9b22a
&merchant-order-id=inv4097763
&paynet-order-id=6768788
&end-point-id=22903
```

The same response when the request includes
`Accept: application/vnd.pay+json`:

```json
{
    "type": "async-response",
    "serial-number": "00000000-0000-0000-0000-000002d9b22a",
    "merchant-order-id": "inv4097763",
    "paynet-order-id": "6768788",
    "end-point-id": "22903"
}
```

#### Interactive Documentation

The full API reference is available online as interactive OpenAPI
documentation — no tools or downloads required. Open it in your browser
to browse every endpoint, review request and response parameters and
data schemas, and send test requests right from the page:

[OpenAPI Interactive Documentation](https://doc.payneteasy.com/integration/openapi-doc.html.md)
 

#### SDK generation

[OpenAPI Generator](https://openapi-generator.tech/) is a free,
open-source tool that reads an OpenAPI specification and generates
ready-to-use client SDKs, server stubs, and documentation for more than
50 languages. Its command-line interface, `openapi-generator-cli`, is
the quickest way to turn the specification above into a working client.

Install it using any of the methods below (see the
[installation guide](https://openapi-generator.tech/docs/installation)
for all the options):

npm

```bash
npm install @openapitools/openapi-generator-cli -g
```

Homebrew

```bash
brew install openapi-generator
```

Docker

```bash
docker pull openapitools/openapi-generator-cli
```

JAR

```bash
# requires Java 11+; replace <version> with the latest release from
# https://github.com/OpenAPITools/openapi-generator/releases
wget https://repo1.maven.org/maven2/org/openapitools/openapi-generator-cli/<version>/openapi-generator-cli-<version>.jar \
    -O openapi-generator-cli.jar
java -jar openapi-generator-cli.jar version
```

Then generate a client in the language of your choice:

Java

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g java \
    -o sdk-java
```

Python

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g python \
    -o sdk-python
```

Type Script

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g typescript-fetch \
    -o sdk-ts
```

PHP

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g php \
    -o sdk-php
```

C#

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g csharp \
    -o sdk-csharp
```

Go

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g go \
    -o sdk-go
```

Ruby

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g ruby \
    -o sdk-ruby
```

Kotlin

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g kotlin \
    -o sdk-kotlin
```

Swift

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g swift5 \
    -o sdk-swift
```

Rust

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g rust \
    -o sdk-rust
```

Dart

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g dart \
    -o sdk-dart
```

C++

```bash
openapi-generator-cli generate \
    -i https://doc.payneteasy.com/openapi.json \
    -g cpp-restsdk \
    -o sdk-cpp
```

#### Using AI Agents

AI coding assistants — such as Claude Code, ChatGPT, Cursor, and
Windsurf — can read an OpenAPI specification and generate a client or
integration automatically.

Copy the prompt below into your AI assistant and adjust the target
language and requirements as needed:

```text
Generate an API client from this OpenAPI specification:

https://doc.payneteasy.com/openapi.json

Requirements:
- target language: Python (or TypeScript, PHP, Java, ...)
- create a typed API client class
- generate request and response models
- include usage examples
```

### Open Cart

The [Paynet Easy plugin for Open Cart](https://github.com/payneteasy/php-plugin-opencart) adds a Paynet Easy
payment method to Open Cart 1.x stores, using the redirect-based payment form integration of the
Payneteasy merchant API. Once installed, customers choose Paynet Easy at checkout and are taken to a
hosted payment form to enter their card details; the order status in Open Cart is then updated automatically
based on the result returned by Payneteasy.

A live example of the plugin running in an Open Cart storefront is available at the
[Open Cart demo shop](https://opencart.codetime.net/).

> **Note:** The instructions below document the Open Cart 1.x plugin ([php-plugin-opencart](https://github.com/payneteasy/php-plugin-opencart)). A separate plugin for Open Cart 4 is published at [php-plugin-opencart-4](https://github.com/payneteasy/php-plugin-opencart-4); it ships as an Open Cart extension with the standard `admin` / `catalog` module layout rather than the Composer-built package described here. If your store runs Open Cart 4, use that repository and follow its README for installation.

#### Source code

The plugin source code, build instructions and issue tracker are available in the
[php-plugin-opencart repository](https://github.com/payneteasy/php-plugin-opencart) on Git Hub. For
Open Cart 4 stores, use the [php-plugin-opencart-4](https://github.com/payneteasy/php-plugin-opencart-4)
repository instead.

### Order Stage

Some APIs provide additional transaction stages, if you’ve receive unlisted transaction status please inform your account manager.
 

| Stage Name | Description | Final Stage |
|----------------------------------|------------------------------------------------------------------------------------------------------------------|---------------|
| AUTH_3D_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_3D_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_APPROVED | Transaction has been approved, final status | Yes |
| AUTH_CANCELLED | Transaction has been declined, final status | Yes |
| AUTH_CARD_CHIP_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_CARD_CHIP_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_CHAIN_DECLINED | Transaction has been declined, but processing is still in progress, non-final status | No |
| AUTH_CUST_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_CUST_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_CUST_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_CUST_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_CUST_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_CUST_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_DECLINED | Transaction has been declined, final status | Yes |
| AUTH_DESCRIPTOR_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_DESCRIPTOR_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| AUTH_FAILED | Transaction has been declined, final status | Yes |
| AUTH_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| AUTH_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_LOAN_REGISTERING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_LOAN_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_LOYALTY_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_LOYALTY_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_PHONE_VERIFICATED | Verification has been finished, you should continue polling, non-final status | No |
| AUTH_PHONE_VERIFICATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_RND_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AUTH_RND_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_TEST_CHECKING | Transaction is being processed, you should continue polling, non-final status | No |
| AUTH_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| AV_3D_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_3D_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_APPROVED | Transaction has been approved, final status | Yes |
| AV_CANCELLED | Transaction has been declined, final status | Yes |
| AV_CHAIN_DECLINED | Transaction has been declined, but processing is still in progress, non-final status | No |
| AV_CUST_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_CUST_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_CUST_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_CUST_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_CUST_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_CUST_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_DECLINED | Transaction has been declined, final status | Yes |
| AV_DESCRIPTOR_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_DESCRIPTOR_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| AV_FAILED | Transaction has been declined, final status | Yes |
| AV_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| AV_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_PHONE_VERIFICATED | Verification has been finished, you should continue polling, non-final status | No |
| AV_PHONE_VERIFICATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_RND_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| AV_RND_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_TEST_CHECKING | Transaction is being processed, you should continue polling, non-final status | No |
| AV_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| CANCEL_APPROVED | Transaction has been approved, final status | Yes |
| CANCEL_DECLINED | Transaction has been declined, final status | Yes |
| CANCEL_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| CANCEL_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| CANCEL_REJECTED | Transaction has been declined, final status | Yes |
| CANCEL_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| CANCEL_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| CAPTURE_APPROVED | Transaction has been approved, final status | Yes |
| CAPTURE_DECLINED | Transaction has been declined, final status | Yes |
| CAPTURE_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| CAPTURE_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| CAPTURE_REJECTED | Transaction has been declined, final status | Yes |
| CAPTURE_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| CAPTURE_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| CHARGEBACK_APPROVED | Transaction has been approved, final status | Yes |
| CREATE_CM_APPROVED | Transaction has been approved, final status | Yes |
| CREATE_CM_CANCELLED | Transaction has been declined, final status | Yes |
| CREATE_CM_DECLINED | Transaction has been declined, final status | Yes |
| CREATE_CM_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| CREATE_CM_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| CREATE_CM_EXTERNAL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| CREATE_CM_EXTERNAL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_FAILED | Transaction has been declined, final status | Yes |
| CREATE_CM_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| CREATE_CM_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_PE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| CREATE_CM_PE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| CREATE_CM_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| CREATE_CM_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| CREATE_CM_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| DELETE_CM_APPROVED | Transaction has been approved, final status | Yes |
| DELETE_CM_CANCELLED | Transaction has been declined, final status | Yes |
| DELETE_CM_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| DELETE_CM_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| DELETE_CM_FAILED | Transaction has been declined, final status | Yes |
| DELETE_CM_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| DELETE_CM_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| DELETE_CM_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| DELETE_CM_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| DELETE_CM_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| DISPUTE_APPROVED | Transaction has been approved, final status | Yes |
| FRAUD_APPROVED | Transaction has been approved, final status | Yes |
| INQUIRE_CM_APPROVED | Transaction has been approved, final status | Yes |
| INQUIRE_CM_CANCELLED | Transaction has been declined, final status | Yes |
| INQUIRE_CM_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| INQUIRE_CM_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| INQUIRE_CM_FAILED | Transaction has been declined, final status | Yes |
| INQUIRE_CM_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| INQUIRE_CM_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| INQUIRE_CM_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| INQUIRE_CM_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| INQUIRE_CM_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| MFO_SCORING_APPROVED | Transaction has been approved, final status | Yes |
| MFO_SCORING_DECLINED | Transaction has been declined, final status | Yes |
| MFO_SCORING_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| MFO_SCORING_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| PAN_ELIGIBILITY_APPROVED | Transaction has been approved, final status | Yes |
| PAN_ELIGIBILITY_CANCELLED | Transaction has been declined, final status | Yes |
| PAN_ELIGIBILITY_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| PAN_ELIGIBILITY_FAILED | Transaction has been declined, final status | Yes |
| PAN_ELIGIBILITY_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| PAN_ELIGIBILITY_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| PAN_ELIGIBILITY_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| PAN_ELIGIBILITY_REJECTED | Transaction has been declined, final status | Yes |
| PAN_ELIGIBILITY_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| PAN_ELIGIBILITY_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| PAYOUT_CHECK_VALIDATING | The availability for payout is still not confirmed, non-final status | No |
| PAYOUT_CHECK_VALIDATED | The availability for payout is confirmed, non-final status | No |
| RETRIEVAL_APPROVED | Transaction has been approved, final status | Yes |
| REVERSAL_APPROVED | Transaction has been approved, final status | Yes |
| REVERSAL_DECLINED | Transaction has been declined, final status | Yes |
| REVERSAL_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| REVERSAL_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| REVERSAL_REJECTED | Transaction has been declined, final status | Yes |
| REVERSAL_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| REVERSAL_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| SALE3D_END_APPROVED | Transaction has been approved, final status | Yes |
| SALE3D_END_DECLINED | Transaction has been declined, final status | Yes |
| SALE3D_END_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| SALE3D_END_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE3D_END_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| SALE_3D_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_3D_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_APPROVED | Transaction has been approved, final status | Yes |
| SALE_AUTO_REVERSAL_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_CANCELLED | Transaction has been declined, final status | Yes |
| SALE_CARD_CHIP_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_CARD_CHIP_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_CHAIN_DECLINED | Transaction has been declined, but processing is still in progress, non-final status | No |
| SALE_CUST_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_CUST_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_CUST_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_CUST_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_CUST_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_CUST_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_DECLINED | Transaction has been declined, final status | Yes |
| SALE_DESCRIPTOR_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_DESCRIPTOR_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_EMV_PROCESSING | Transaction is being processed, sending 0200 to an Acquirer, you should continue polling, non-final status | No |
| SALE_EMV_VALIDATING | Transaction is being processed, waiting for 2nd Gen AC from a chip, you should send EMV Final Advice to a host | No |
| SALE_EMV_VALIDATED | Transaction is being processed, EMV Final Advice is received, you should continue polling, non-final status | No |
| SALE_EMV_ADVICE_PROCESSING | Transaction is being processed, sending 0220 to an Acquirer, you should continue polling, non-final status | No |
| SALE_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| SALE_FAILED | Transaction has been declined, final status | Yes |
| SALE_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| SALE_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_LOYALTY_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_LOYALTY_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_PHONE_VERIFICATED | Verification has been finished, you should continue polling, non-final status | No |
| SALE_PHONE_VERIFICATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_RND_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| SALE_RND_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_TEST_CHECKING | Transaction is being processed, you should continue polling, non-final status | No |
| SALE_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| TRANSFER_3D_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_3D_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_APPROVED | Transaction has been approved, final status | Yes |
| TRANSFER_BALANCE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_BALANCE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_CANCELLED | Transaction has been declined, final status | Yes |
| TRANSFER_CARD_CHIP_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_CARD_CHIP_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_CHAIN_DECLINED | Transaction has been declined, but processing is still in progress, non-final status | No |
| TRANSFER_CHECK_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_CHECK_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_CUST_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_CUST_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_CUST_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_CUST_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_CUST_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_CUST_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_DECLINED | Transaction has been declined, final status | Yes |
| TRANSFER_DESCRIPTOR_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_DESCRIPTOR_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| TRANSFER_FAILED | Transaction has been declined, final status | Yes |
| TRANSFER_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| TRANSFER_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_LOYALTY_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_LOYALTY_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_PHONE_VERIFICATED | Verification has been finished, you should continue polling, non-final status | No |
| TRANSFER_PHONE_VERIFICATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_RND_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| TRANSFER_RND_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_TEST_CHECKING | Transaction is being processed, you should continue polling, non-final status | No |
| TRANSFER_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| UPDATE_CM_APPROVED | Transaction has been approved, final status | Yes |
| UPDATE_CM_CANCELLED | Transaction has been declined, final status | Yes |
| UPDATE_CM_DECLINED | Transaction has been declined, final status | Yes |
| UPDATE_CM_EMAIL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| UPDATE_CM_EMAIL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| UPDATE_CM_EXTERNAL_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| UPDATE_CM_EXTERNAL_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_FAILED | Transaction has been declined, final status | Yes |
| UPDATE_CM_FILTERED | Transaction has been declined by fraud internal or external control systems, final status | Yes |
| UPDATE_CM_FILTERING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_PE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| UPDATE_CM_PE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_PHONE_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| UPDATE_CM_PHONE_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_TWITTER_VALIDATED | Transaction is being processed, internal stage have been finished, you should continue polling, non-final status | No |
| UPDATE_CM_TWITTER_VALIDATING | Transaction is being processed, you should continue polling, non-final status | No |
| UPDATE_CM_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |
| VOID_APPROVED | Transaction has been approved, final status | Yes |
| VOID_ERROR | The status of transaction is unknown, please inform your account manager, final status | Yes |
| VOID_PROCESSING | Transaction is being processed, you should continue polling, non-final status | No |
| VOID_REJECTED | Transaction has been declined, final status | Yes |
| VOID_STARTING | Transaction is being processed, you should continue polling, non-final status | No |
| VOID_UNKNOWN | Transaction has been declined but something went wrong, please inform your account manager, non-final status | No |

### os Commerce

The os Commerce plugin lets an [os Commerce](https://www.oscommerce.com/) 4 store accept card payments processed through Payneteasy. Shoppers pay on a hosted payment form without leaving the checkout flow, and the module also adds an optional surcharge fee line to the order totals.

A live demo storefront with the plugin installed is available at [oscommerce.codetime.net](https://oscommerce.codetime.net), and you can walk through a full checkout there before installing the module on your own shop.

#### Source code

The plugin is developed in the open on Git Hub: [payneteasy/php-plugin-oscommerce-4](https://github.com/payneteasy/php-plugin-oscommerce-4). Download the `plugin-oscommerce.zip` release archive from that repository for either of the installation methods below.

### PAN Eligibility

#### Introduction

PAN Eligibility services allow Connecting Party to detect whether card is eligible for Money Transfer (either as sending or as receiving card) along with providing extended information about card issuer and card product before making a financial transaction request.

#### PAN Eligibility Direct Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/pan-eligibility/send/
activate B
A -> B: /api/v2/pan-eligibility/receive/
A -> B: /api/v2/pan-eligibility/both/
B --> A: Order ID
B -> B: Process\npan-eligibility
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2,3,4) To implement PAN eligibility direct flow request see [/api/v2/pan-eligibility/](https://doc.payneteasy.com/integration/API_commands/api_v2_pan-eligibility.html.md). PAN eligibility information can be requested for Payer card (also referred as Sender), Recipient card (also referred as Receiver) or both cards at once.
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### PAN Eligibility Form Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Purchase payment request ==
  Merchant -> g: api/v2/pan-eligibility/send-form
  activate g
  Merchant -> g: api/v2/pan-eligibility/receive-form
  Merchant -> g: api/v2/pan-eligibility/both-form
  g --> Merchant: Redirect-url, orderId
  deactivate g
  Merchant -> Customer: Provide redirect-url \nto payer’s browser
  deactivate Merchant
  activate Customer
  Customer -> g: GET redirect-url
  deactivate Customer
  activate g
  g --> Customer: Payment Form
  deactivate g
  activate Customer
  Customer -> g: Submit form
  deactivate Customer
  activate g
  g --> g: Process PAN Eligibility
  == Final redirect of customer ==
  g -> Customer: Connecting Party website redirect_url
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  activate Merchant
  group Get Final Status
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant --> Customer: Show result
  deactivate Merchant
```

(2,3,4) To implement PAN eligibility form flow request see [/api/v2/pan-eligibility-form/](https://doc.payneteasy.com/integration/API_commands/api_v2_pan-eligibility-form.html.md). PAN eligibility information can be requested for Payer card (also referred as Sender), Recipient card (also referred as Receiver) or both cards at once.
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### PAN Eligibility Callback

##### Callback Parameters

Additional parameters are sent in callbacks for PAN Eligibility transactions. For more information see [Connecting Party Callback Parameters](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).

| Callback Parameter | Description |
|---------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| status | See [Status List](https://doc.payneteasy.com/integration/reference/statuses.html.md) for details. |
| serial-number | Serial number of the request. |
| client_orderid | Connecting Party order identifier. |
| paynet-order-id | Order id set by Payneteasy. |
| processor-tx-id | Transaction id set by processor. |
| type | Transaction type, sale reversal chargeback |
| sending-card-type | The sending card type (VISA, MASTERCARD). |
| sending-cardholder | Cardholder of the sending card. |
| sending-bin | The sending card Bank identification number. |
| sending-last-four-digits | The sending card last 4 digits. |
| sending-eligible | Whether the sending card is eligible for sending funds. Possible values: true/false/unknown. |
| sending-ica | The sending card ICA. |
| sending-bank-name | The sending card Bank name. |
| sending-currency-code | The sending card currency code. |
| sending-country-code | The sending card country code. |
| sending-acceptance-brand-code | The sending card Acceptance brand code. |
| sending-acceptance-brand-name | The sending card Acceptance brand name. |
| sending-product-brand-code | The sending card Product brand code. |
| sending-product-brand-name | The sending card Product brand name. |
| receiving-card-type | The receiving card type (VISA, MASTERCARD). |
| receiving-bin | The receiving card Bank identification number. |
| receiving-last-four-digits | The receiving card last 4 digits. |
| receiving-eligible | Whether the receiving card is eligible for sending funds. Possible values: true/false/unknown. |
| receiving-ica | The receiving card ICA. |
| receiving-bank-name | The receiving card Bank name. |
| receiving-currency-code | The receiving card currency code. |
| receiving-country-code | The receiving card country code. |
| receiving-acceptance-brand-code | The receiving card Acceptance brand code. |
| receiving-acceptance-brand-name | The receiving card Acceptance brand name. |
| receiving-product-brand-code | The receiving card Product brand code. |
| receiving-product-brand-name | The receiving card Product brand name. |
| error-code | Error Code. |
| error-message | Error Message. |
| control | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Callback parameter: status. 2. Callback parameter: orderid. 3. Callback parameter: merchant_order. 4. merchant_control (Control key assigned to Merchant account in the Payneteasy Payment Gateway). |

##### Callback Macros

Simple callback URL contains all parameters listed in [Callback Parameters](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md). Customizable URL allows Connecting Party to define own parameter names, whereas the actual parameters values are defined by use of macros with the following format ${parameter_name}. Available macros are listed in [Callback Macros](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).

| Field Name Macro | Field Value Macro | Description |
|------------------------------------|---------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ${status} | n/a | Transaction status, approved declined processing. |
| ${serial-number} | n/a | Unique number assigned by Payneteasy server to particular request from the Connecting Party. |
| ${client-order-id} | n/a | Unique order identifier assigned by Connecting Party. |
| ${paynet-order-id} | n/a | Payneteasy-generated order id. |
| ${processor-tx-id} | n/a | Processor-generated transaction id. |
| ${type} | n/a | Transaction type, ex. sale, return, chargeback, etc. |
| ${sending-card-type} | n/a | The sending card type (VISA, MASTERCARD). |
| ${sending-cardholder} | n/a | Cardholder of the sending card. |
| ${sending-bin} | n/a | The sending card Bank identification number. |
| ${sending-last-four-digits} | n/a | The sending card last 4 digits. |
| ${sending-eligible} | n/a | Whether the sending card is eligible for sending funds. Possible values: true/false/unknown. |
| ${sending-ica} | n/a | The sending card ICA. |
| ${sending-bank-name} | n/a | The sending card Bank name. |
| ${sending-currency-code} | n/a | The sending card currency code. |
| ${sending-country-code} | n/a | The sending card country code. |
| ${sending-acceptance-brand-code} | n/a | The sending card Acceptance brand code. |
| ${sending-acceptance-brand-name} | n/a | The sending card Acceptance brand name. |
| ${sending-product-brand-code} | n/a | The sending card Product brand code. |
| ${sending-product-brand-name} | n/a | The sending card Product brand name. |
| ${receiving-card-type} | n/a | The receiving card type (VISA, MASTERCARD). |
| ${receiving-bin} | n/a | The receiving card Bank identification number. |
| ${receiving-last-four-digits} | n/a | The receiving card last 4 digits. |
| ${receiving-eligible} | n/a | Whether the receiving card is eligible for sending funds. Possible values: true/false/unknown. |
| ${receiving-ica} | n/a | The receiving card ICA. |
| ${receiving-bank-name} | n/a | The receiving card Bank name. |
| ${receiving-currency-code} | n/a | The receiving card currency code. |
| ${receiving-country-code} | n/a | The receiving card country code. |
| ${receiving-acceptance-brand-code} | n/a | The receiving card Acceptance brand code. |
| ${receiving-acceptance-brand-name} | n/a | The receiving card Acceptance brand name. |
| ${receiving-product-brand-code} | n/a | The receiving card Product brand code. |
| ${receiving-product-brand-name} | n/a | The receiving card Product brand name. |
| ${error-code} | n/a | Error Code. |
| ${error-message} | n/a | Error Message. |
| ${control} | n/a | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. Callback parameter: status. 2. Callback parameter: orderid. 3. Callback parameter: merchant_order. 4. merchant_control (Control key assigned to Merchant account in the Payneteasy Payment Gateway). |

### Pax Manual

#### Руководство администратора

##### Перевод терминала Pax в режим работы через USB-порт

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Связь с банком / Через кассу
* Параметры / Редактирование / Smart Sale / Порт терминала / USB
* Параметры / Редактирование / Smart Sale / SSL без ККМ / Да

1. Отключить терминал от USB и подключить его обратно.

<iframe width="871" height="490" src="https://www.youtube.com/embed/S_QGNcmR2tU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Переключение терминала в режим работы с USB порта на Ethernet

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Связь с банком / Через терминал
* Параметры / Редактирование / Smart Sale / Порт терминала / Ethernet

1. Отключить терминал от USB и подключить его обратно.

<iframe width="871" height="490" src="https://www.youtube.com/embed/x Dm Av Zl YfEU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Настройка терминала на работу без кассы

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Режим ККМ / Касса или Терминал (по умолчанию - Касса)

1. После установки параметра терминал перезагрузится и в меню появится иконка для инициации платежа.

> **Note:** В этом режиме терминала Pax SP30 печать слипов (чеков платежной системы) невозможна, т.к. принтер отсутствует.

##### Создание нового кассира

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Управление доступом / Управление правами / Новый оператор - создать нового оператора в группу “Кассиры” и установить пароль (на этапе “Введите карту доступа” нажать Enter).
* Параметры / Управление доступом / Авто логин - выбрать нужного оператора (в случае необходимости).

##### Вход меню Администратора

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт меню “Блокировка терм.” и нажать ENTER.
4. Выбрать пункт “Администратор” и ввести пароль Администратора.
5. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
6. Ввести пароль 1234 и нажать ENTER.

##### Вход в системное меню

1. При включении зажать кнопку “Func”.
2. При появлении надписи SELF-TEST SUCCESS зажать кнопку “Cancel”.

#### Руководство пользователя

##### Подключение терминала к сети Ethernet

1. Подключить кабель к разъему с надписью ETH.
2. На роутере найти IP-адрес терминала по его MAC-адресу и закрепить его на DHCP-сервере роутера за терминалом. MAC-адрес терминала написан на желтой этикетке на нижней панели терминала.
3. При включении терминал должен успешно установить соединение с сервером.
4. Выгрузить логи на сервер (2+ENTER) и запросить у службы поддержки IP-адрес для терминала в системе управления.

##### Нахождение IP-адреса терминала в сети

Поиск IP-адреса Pax/Verifone в сети производится самостоятельно. Указание диапазона не обязательно.

Ограничения:

* Маска сети не должна выдавать больше 500 IP адресов.
* При нахождении больше одного терминала отобразится ошибка.

> **Note:** В случае присутствия больше одного терминала в сети, может быть указан его идентификатор (например, terminal_id=12345678) после чего терминал может быть проверен.

Правила для заполнения поля address:

* В случае присутствия в сети одного терминала и количество IP-адресов меньше 500, нет необходимости вводить данные.
* В случае присутствия в сети больше одного терминала и количество IP-адресов меньше 500, необходимо ввести идентификатор терминала (например, terminal_id=12345678).
* В случае присутствия в сети одного терминала и количество IP-адресов больше 500 IP-адресов, необходимо указать диапазон поиска IP-range (например, range=192.168.0.1-192.168.0.254).
* В случае присутствия в сети больше одного терминала и количество IP-адресов больше 500, необходимо ввести идентификатор терминала или диапазон поиска IP-range на выбор.

> **Note:** Установка программы для поиска терминала на [iOS](https://dengisend.ru/demo-ios/Socket Scaner/install.html) и [Android](https://mpos.pne.io/verifone/scanner/scanner.apk).

##### Автоматический поиск терминала (только для IOS)

* В настройках терминала прописать диапазон, в котором будет находится терминал (например, range=10.45.69.1-10.45.69.254:27015).

##### Обновление конфигурации

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 3 и ENTER одновременно.
2. Ввести пароль 1234 и нажать ENTER.
3. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

* В случае подключения терминала по USB, после отображения сообщения Загрузка параметров будет отложена нажать ENTER.
* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

<iframe width="871" height="490" src="https://www.youtube.com/embed/MSlpEIaO0B0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Нажать на ENTER (курсор на пункте ЗАГРУЗКА ПАРАМ.).
5. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

* В случае подключения терминала по USB, после отображения сообщения Загрузка параметров будет отложена нажать ENTER. Затем необходимо произвести оплату, во время которой будет произведено обновление конфигурации.
* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

##### Отправка логов на сервер

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 2 и ENTER одновременно.
2. В случае подключения терминала по USB, после отображения сообщения Выгрузка логов будет отложена нажать ENTER.

* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

<iframe width="871" height="490" src="https://www.youtube.com/embed/RHGZGYRx64k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Выбрать пункт меню Логирование.
5. Выбрать пункт Выгрузка лога.
6. В случае подключения терминала по USB, после отображения сообщения Выгрузка логов будет отложена нажать ENTER. Затем необходимо произвести оплату, во время которой будет произведено обновление конфигурации.

* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

#### FAQ

##### Каждое утро Pax при первой оплате очень долго чем-то занимается, после чего выдает ошибку “Оплата не прошла, используйте другую карту”.

В случае подключения терминала по USB, происходит сверка итогов. Процесс сверки может происходить только во время проведения транзакции.
 

> **Note:** Процесс сверки логов происходит каждый день в 10:00 GMT+0.

Рекомендация: Проведение пустой транзакции утром следующего дня.
 

##### При попытке оплаты или загрузке возникает ошибка “Нет соединения с хостом”. Терминал подключен по USB.

Рекомендация: Отключить терминал, включить и проверить настройки для работы по USB.
 

> **Note:** Необходимо использование USB-кабеля старого типа, т.к. работа USB-кабеля нового типа может быть некорректной.

Возможен недостаток питания терминала от кассы АТОЛ-150. Можно поставить USB-hub с отдельным питанием или поставить Verifone Vx820.
 
В случае наличия провода с разветвлением на LAN, возможна организация работы через роутер. Также возможно дополнительное питание терминала через разъемы микро-usb/мини-usb, в случае наличия их в кабеле.
 

##### Подключённый к стороней кассе Pax не принял карту, но на кассу отдал команду печати фискального документа.

Логи по сторонним кассам есть только у вас, у нас в этом случае не пишутся.
 

##### Как осуществить сверку итогов принудительно на терминале?

Рекомендация: Зажать на терминале клавиши 4 и Enter одновременно.
 

##### Эвотор теряет связь с терминалом по USB (на Эвоторе отображается ошибка “Прерывание связи”).

* Полностью удалить терминал с Эвотора, перезагрузить Эвотор и терминал.
* Переподключить терминал к другому порту.
* Привязать терминал, проверить настройки Эвотора - что указан верный номер терминала и стоит галка по умолчанию.
* Проверить настройки терминала:

Параметры / Редактирование / Smart Sale / Связь с банком.
Параметры / Редактирование / Smart Sale / Порт терминала.
Параметры / Редактирование / Smart Sale / SSL без ККМ.
Если есть возможность переподключить терминал по Ethernet кабелю.

### Payment Cashier

#### Introduction

Payment Cashier integration allows Payer to choose the payment method for transaction. Payment Cashier can be configured on the Connecting Party side or the Payment Gateway (it is also referred to as Parallel Form) side which is covered in this Use-Case. Connecting Party redirects the Payer to Parallel Form hosted on the Payment Gateway side, the Payer selects one of the available payment methods and tries to perform the payment. Parallel Form can initiate sale or preauth transactions for each configured payment method. Once the transaction is successful, the Payer gets redirected back to the Connecting Party. For more information please see [Payment Flow Customization](#payment-flow-customization-url).
 
To see how the forms can be customized, please follow the [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) reference to see examples and macros of [Payment Cashier Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Payment Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Prefilled Cardholder Data in Payment Page](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Wait Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), and [Finish Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md).
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Payment Cashier configured in the Payment Gateway has internal structure of Master Endpoints that combine regular Endpoints. Regular Endpoints connected to the Master Endpoint are called Auxiliary Endpoints. Each Auxiliary Endpoint is configured for specific payment method. When making a payment, the Payer can choose the payment method on the Parallel Form. When Payer selects the payment method, Parallel Form initiates an auxiliary transaction on the corresponding Auxiliary Endpoint. If Auxiliary Endpoint currency is different from Master Endpoint currency, the master transaction amount will be converted to respective currency of this payment method. Additionally, Master Endpoints can be consolidated in the Endpoint Group to create single logical unit for multi-currency integrations. See the [Options for multi-currency integration](#cashier-multicurrency) and select the preferred option with Payneteasy support manager.
 

#### Payment Cashier Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Payment cashier request ==
  Merchant -> g: api/v2/sale-form
  activate g
  g --> Merchant: Redirect-url, orderId
  deactivate g
  Merchant -> Customer: Provide redirect-url \nto Payer’s browser
  deactivate Merchant
  activate Customer
  Customer -> g: GET redirect-url
  deactivate Customer
  activate g
  g --> Customer: Return parallel form
  deactivate g
  activate Customer
  Customer --> Customer: Payer selects payment method
  activate Customer
  Customer -> g: Parallel form requests selected payment method transaction
  deactivate Customer
  activate g
  g --> g: Initiate auxiliary transaction for \nselected payment method
  g --> Customer: Return auxiliary form
  deactivate g
  alt if Payer opens another parallel form  payment tab
  Customer --> Customer: Payer selects payment method
  activate Customer
  Customer -> g: Parallel form requests selected payment method transaction
  deactivate Customer
  activate g
  g --> g: Initiate auxiliary transaction for \nselected payment method
  g --> Customer: Return another auxiliary form
  deactivate g
  end
  Customer -> g: Submit form
  deactivate Customer
  activate g
  g --> g: Process payment
  == Final redirect of Payer ==
  g -> Customer: Connecting Party website redirect_url
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  group Get Final Status
  == Receive Connecting Party Callback ==
  activate Merchant
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant --> Customer: Show result
  deactivate Merchant
```

(2) To implement a sale-form request see [/api/v2/sale-form/](https://doc.payneteasy.com/integration/API_commands/api_v2_sale-form.html.md).
 
(14) To implement the final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(16,17) To implement an order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5-second intervals until final status will be received in response.
 
(18) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md). Callback is sent with the status of the master transaction (cashier transactions). To get additional callbacks about the result of each initiated transactions, please contact Payneteasy support manager.
 

#### Options For Multi-Currency Integration

Payment Cashier can be configured for multiple currencies. For each transaction currency required by Connecting Party, a separate Master Endpoint with unique ID is created. In order to avoid integration to new Master Endpoint IDs for additional currencies support in future, Connecting Party can choose integration to Endpoint Group instead. Endpoint Group is a single logical unit which consolidates Master Endpoints in different currencies. Master Endpoints in new currencies can be added to the same Endpoint Group in future.

```plantuml
title Options for multi-currency processing integration
package "Integration to Endpoint Group" {
  class "layoutHelper1" #ffe6cc;line:black;line.dotted
  class "Payment\nmethod 1\ncurrency A" #ffe6cc;line:black;line.dotted
  class "Payment\nmethod 2\ncurrency A" #ffe6cc;line:black;line.dotted
  class "Payment\nmethod 1\ncurrency B" #dae8fc;line:black;line.dotted
  class "Payment\nmethod 2\ncurrency X" #daf9fc;line:black;line.dotted
  class "Master Endpoint\n currency A" #ffe6cc;line:black;line.dotted
  class "Master Endpoint\n currency B" #dae8fc;line:black;line.dotted
  class "Endpoint\nGroup" #ffcdcc;line:black;line.dotted
}
package "Integration to multiple Master Endpoints" {
class "layoutHelper2\n" #ffe6cc;line:black;line.dotted
  class "Payment\nmethod 1\ncurrency C" #e1d5e7;line:black;line.dotted
  class "Payment\nmethod 2\ncurrency C" #e1d5e7;line:black;line.dotted
  class "Payment\nmethod 1\ncurrency D" #dafcdd;line:black;line.dotted
  class "Payment\nmethod 2\ncurrency Y" #abf8d8;line:black;line.dotted
  class "Master Endpoint\n currency C" #e1d5e7;line:black;line.dotted
  class "Master Endpoint\n currency D" #dafcdd;line:black;line.dotted
}
class "layoutHelper3" #ffe6cc;line:black;line.dotted
class "Connecting Party\n (Merchant)" #ececec;line:black;line.bold

"Connecting Party\n (Merchant)" -left-> "Endpoint\nGroup"
"Connecting Party\n (Merchant)" -down-> "layoutHelper3"
"Connecting Party\n (Merchant)" -down-> "Master Endpoint\n currency C"
"Connecting Party\n (Merchant)" -down-> "Master Endpoint\n currency D"

"Endpoint\nGroup" -down- "Master Endpoint\n currency A"
"Endpoint\nGroup" -down- "Master Endpoint\n currency B"
"Master Endpoint\n currency C" -down- "Payment\nmethod 1\ncurrency C"
"Master Endpoint\n currency C" -down- "Payment\nmethod 2\ncurrency C"
"Master Endpoint\n currency D" -down- "Payment\nmethod 1\ncurrency D"
"Master Endpoint\n currency D" -down- "Payment\nmethod 2\ncurrency Y"
"Master Endpoint\n currency A" -down- "Payment\nmethod 1\ncurrency A"
"Master Endpoint\n currency A" -down- "Payment\nmethod 2\ncurrency A"
"Master Endpoint\n currency B" -down- "Payment\nmethod 1\ncurrency B"
"Master Endpoint\n currency B" -down- "Payment\nmethod 2\ncurrency X"
"Connecting Party\n (Merchant)" -left[hidden]- "layoutHelper1"
"Connecting Party\n (Merchant)" -right[hidden]- "layoutHelper2\n"
"layoutHelper1" -[hidden]- "Master Endpoint\n currency A"
"layoutHelper1" -[hidden]- "Master Endpoint\n currency B"
"layoutHelper2\n" -[hidden]- "Master Endpoint\n currency C"
"layoutHelper2\n" -[hidden]- "Master Endpoint\n currency D"
hide members
hide circle
hide layoutHelper1
hide layoutHelper2\n
hide layoutHelper3
```

#### Payment Flow Customization Scenarios

##### Callback Notification Options

By default, callbacks have the following form:
 
 
Master Endpoint Callback: client_orderid=A&orderid=B
 
Auxiliary Endpoint Callback: client_orderid=A&orderid=C (if it is set on an Auxiliary Endpoint)
 
 
For correct callback handling on Connecting Party side it is important to note that the callback from the Auxiliary Endpoint may come earlier than the callback from the Master Endpoint (because final status on auxiliary transaction triggers final status on master transaction).
 
 
There is another setup that can be preferred over the default one (to enable this feature please contact Payneteasy support manager) :
 
 
Master Endpoint Callback: client_orderid=A&orderid=B
 
Auxiliary Endpoint Callback: client_orderid=B&orderid=C (if it is set on an Auxiliary Endpoint)
 
 
A callback on the Auxiliary Endpoint may be required in two cases:
 
 
1. The Connecting Party wants to have complete information about all payment attempts on the Payment Cashier.
 
2. The Connecting Party implements preauth -> capture/cancel integration on the Payment Cashier. Capture/cancel transactions can be initiated for approved preauth transaction with request sent to Master Endpoint ID by using orderid of the auxiliary transaction. This orderid comes in a callback from an Auxiliary Endpoint when preauth transaction receives the final status.
 

##### Redirect Payer After Any Decline

By default, the Payer stays on the Parallel Form if one of the auxiliary transactions is declined, so the Payer can try to pay with another available payment method.
There is an option to redirect the Payer to the Connecting Party’s website after receiving an unsuccessful status (decline, filtered, error, etc.) on any payment method tab of the Cashier (auxiliary transaction decline will cause the decline on the master transaction). Please contact Payneteasy support manager to enable this feature.

##### Keep Payer on Finish Page

When one of the auxiliary transactions is approved, Parallel Form redirects the Payer back to the Connecting Party’s website (see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md)).
There is an option to keep the Payer on Finish Page instead of redirecting for approved auxiliary transaction (it might be useful if Payment Cashier is displayed in an iframe on the Connecting Party’s website). Please contact Payneteasy support manager to enable this feature.

##### Forced Payer Redirect

If it is necessary to redirect the Payer to the Finish Page while transaction remains in process, the following code must be added to the forms mentioned below:

###### Option 1

Auxiliary Finish Form Template:

```html
<script>
        function backToMerchant() {
            window.parent.postMessage(
                "redirect-to-merchant",
                "https://pay.connectingparty.com"
            );
        }
    </script>
</head>
<body onload="backToMerchant()">

        <h2 class="summary__title">Deposit <span class="status-title">${STATUS}</span></h2>

            <a class="link" href="#" onclick="backToMerchant()">Back to merchant website</a>

```

Master Payment Form Template:

```html
<script>
    window.addEventListener("message", function(event) {
        if (event.origin !== "https://pay.connectingparty.com")
            return;
        if (event.data === "redirect-to-merchant") {
            window.location.replace("https://connectingparty.com/result");
        }
    }, false);
</script>
```

###### Option 2

Auxiliary Finish Form Template:

```html

        <h2 class="summary__title">Deposit <span class="status-title">${STATUS}</span></h2>

            <a class="link" target="_parent" href="${CUSTOMER_REDIRECT_URL}">Back to merchant website</a>

```

#### Subsequent Transactions on Payment Cashier

If the Connecting Party wants to initiate cancel, reversal or capture transactions on Payment Cashier, then Connecting Party needs to send a request to the Master Endpoint ID by using an auxiliary transaction’s order_id. This value can be received in callback from Auxiliary Endpoint together with other details about this transaction. See [Callback Notification Options](#payment-flow-customization-url) for details and check the transaction flow below.

##### Cancel Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Cancel
  activate A
  end
  == Cancel ==
  A -> B: api/v2/return
  activate B
  B --> A: Order ID
  B -> B: Process Cancel
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Cancel can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

##### Capture Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Capture
  activate A
  end
  == Capture ==
  A -> B: api/v2/capture
  activate B
  B --> A: Order ID
  B -> B: Process Capture
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Capture can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

##### Reversal Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Sale or Capture transaction
  autonumber
  group Optional
  Payer -> A: Initiate Return
  activate A
  end
  == Return ==
  A -> B: api/v2/return
  activate B
  B --> A: Order ID
  B -> B: Process Return
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Return can be initiated by Connecting Party based on internal business process or by Payer’s request.
 
(2) To implement return request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Return will be sent only if notify_url was provided in initial transaction request or additional callback URL for Return transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Return will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business process or Payer’s request.

### Payout By Reference

#### Introduction

Payout-by-ref is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) bank card, banking account or digital wallet. Payout transaction in most cases is used for bank account funding.
 
Receiver account Card Reference ID (destination-card-ref-id) for Payout By Reference can be obtained on Card registration step, see card-ref-id in [v2/create-card-ref](https://doc.payneteasy.com/integration/API_commands/api_v2_create-card-ref.html.md) or [v4/create-card-ref](https://doc.payneteasy.com/integration/API_commands/api_v4_create-card-ref.html.md).
 
Card registration requires a previously made transaction in final status, so Payout-by-ref can be initiated only for already registered Receivers.
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Payout Flow

```plantuml
@startuml
participant Receiver as R
participant "Connecting Party" as cp
autonumber
group Optional
R -> cp : Checkout
activate cp
end
== Payout request ==
cp -> "Payneteasy": /api/v4/payout-by-ref/
activate "Payneteasy"
"Payneteasy" --> cp: Order ID
deactivate cp
== Receive Connecting Party Callback ==
"Payneteasy" --> "Payneteasy": Processing\nPayout
group Get Final Status
cp <- "Payneteasy" : Callback with Final Status
"Payneteasy" <-- cp: HTTP 200
deactivate "Payneteasy"
== Order Status request ==
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> cp : Response\nstatus,order-stage
deactivate "Payneteasy"
end
group Optional
cp --> R: Show result
deactivate cp
end
@enduml
```

(1) Payout-by-ref can be initiated by Connecting Party based on internal business model or Receiver’s request.
 
(2) To implement payout-by-ref transaction see [/api/v4/payout-by-ref/](https://doc.payneteasy.com/integration/API_commands/api_v4_payout-by-ref.html.md).
 
(5) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(7) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.

### Payout Form

#### Introduction

Payout-form is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) banking account or digital wallet. Payout-form transaction in most cases is used for bank account funding. Unlike Server-to-Server Payout integration, in which Connecting Party sends receiver account in initial request, Payout Form integration allows the receiver to submit the banking account credentials on the form hosted on Payneteasy side.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
1. Receiver fill out a payout form and sends data;

1. Contextual data is gathered by Payneteasy to process the transaction;

1. Receiver’s browser gets redirected to the Connecting Party website to the resultant page.

#### Payout Form Flow

```plantuml
participant Receiver as R
participant "Connecting Party" as Cp
autonumber
group optional
R -> Cp : Checkout
activate Cp
end
== Payout form request ==
Cp -> "Payneteasy": /api/v4/payout-form/
activate "Payneteasy"
"Payneteasy" --> Cp: Order ID\nredirect-url
deactivate "Payneteasy"
Cp --> R : Redirect to Payout Form\nredirect-url
deactivate Cp
activate R
R -> "Payneteasy" : GET redirect-url
deactivate R
activate "Payneteasy"
"Payneteasy" --> R : Payout Form
deactivate "Payneteasy"
activate R
R -> "Payneteasy" : Submit Form
deactivate R
activate "Payneteasy"
"Payneteasy" --> "Payneteasy" : Process payout
== Final redirect of Receiver ==
"Payneteasy" --> R : Connecting Party website redirect_url
activate R
R -> Cp : POST status,Order ID
deactivate R
activate Cp
group Get Final Status
== Receive Connecting Party Callback ==
Cp <- "Payneteasy" : Callback with Final Status
"Payneteasy" <-- Cp: HTTP 200
deactivate "Payneteasy"
== Order Status request ==
Cp -> "Payneteasy": Get status by Order ID\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> Cp : Response\nstatus,order-stage
deactivate "Payneteasy"
end
group Optional
Cp --> R: Show result
deactivate Cp
end
```

(1) Payout-form can be initiated by Connecting Party based on internal business model or Receiver’s request.
 
(2) To implement payout-form see [/api/v2/payout-form](https://doc.payneteasy.com/integration/API_commands/api_v2_payout_form.html.md).
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(13) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(15) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.

### Payout with bank confirmation

#### Introduction

Payout is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) banking account or digital wallet. This Use-Case describes the integration of payouts which require additional confirmation from the bank.
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Payout Flow

```plantuml
participant Receiver as R
participant "Connecting Party" as cp
autonumber
group Optional
R -> cp : Checkout
activate cp
end
== Payout request ==
cp -> "Payneteasy": /api/v4/payout-check/
activate "Payneteasy"
"Payneteasy" --> cp: Order ID
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
"Payneteasy" --> cp : Response\nstatus,order-stage
cp -> "Payneteasy": /api/v4/payout-pay/
"Payneteasy" --> cp : Response payout-pay
group Conditional
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
"Payneteasy" --> cp : Response\nstatus,redirect-to
cp -> R: Provide redirect URL
deactivate "Payneteasy"
deactivate cp
activate R
R -> "Payneteasy": Redirect by redirect-to
deactivate R
activate "Payneteasy"
"Payneteasy" -> R: Additional Submit Form
deactivate "Payneteasy"
activate R
R -> "Payneteasy": Submit Form
deactivate R
activate "Payneteasy"
end
"Payneteasy" --> "Payneteasy": Processing\nPayout
group Get Final Status
== Receive Connecting Party Callback ==
cp <- "Payneteasy" : Callback with Final Status
"Payneteasy" <-- cp: HTTP 200
deactivate "Payneteasy"
== Order Status request ==
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> cp : Response\nstatus,order-stage
deactivate "Payneteasy"
end
group Optional
cp --> R: Show result
deactivate cp
end
```

(1) Payout can be initiated by Connecting Party based on internal business model or Receiver’s request.
 
(2) To initiate payout, implement payout-check request, see /api/v4/payout-check/.
 
(4) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(5) The order-stage parameter should be payout_check_validated. If payout_check_validating is received, the payout request is not confirmed by the bank yet. In this case the Connecting party should continue to request transaction status.
 
(6) To continue payout processing, implement payout-pay request, see /api/v4/payout-pay/.
 
(9) Some payout methods require the Receiver to fill the additional data on the form. The form to redirect the customer will return in status response in redirect-to parameter.
 
(12) The Receiver submits the payout form.
 
(13) The Receiver gets redirected back to Connecting Party. See [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(15) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(17) Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(19) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.

### PHP Framework

If your website or application is not built on one of the supported CMS or
e-commerce platforms, you can integrate with Payneteasy directly from
plain PHP using the official PHP client library. The library wraps the
Payneteasy Merchant API (request signing, transport, response
parsing and payment status handling) into a set of PHP classes, so you do
not have to implement the API protocol yourself.

The library implements the following payment scenarios:

1. Account verification
2. Sale transactions
3. Preauth/Capture transactions
4. Transfer transactions
5. Return transactions
6. Recurrent transactions
7. Payment Form integration
8. Merchant callbacks

Buy Now Button, e Check, Western Union, Bitcoin, Loan and Qiwi integrations
are listed in the library’s own documentation as not yet implemented.

#### Source code

The library is published on Git Hub: [payneteasy/php-library-payneteasy-api](https://github.com/payneteasy/php-library-payneteasy-api).
The repository README links to more detailed documentation pages (in
English and Russian) describing the library’s internal structure and each
payment scenario in more depth.

### Preauth Form, Capture and Cancel

#### Introduction

Preauthorization 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. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards). Preauth Form integration allows Connecting Party to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted payment form in PCI DSS certified environment.
 
[Capture](#capture-form-request-url) is a transaction followed after preauth which deducts the locked amount from Payer’s card.
 
[Cancel](#cancel-form-request-url) is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card.
 
All forms can be customized. Follow the [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) reference to see examples and macros of [Payment Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Prefilled Cardholder Data in Payment Page](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Wait Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) and [Finish Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md).
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Preauth Form Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Purchase payment request ==
  Merchant -> g: api/v2/preauth-form
  activate g
  g --> Merchant: Redirect-url, orderId
  deactivate g
  Merchant -> Customer: Provide redirect-url \nto payer’s browser
  deactivate Merchant
  activate Customer
  Customer -> g: GET redirect-url
  deactivate Customer
  activate g
  g --> Customer: Payment Form
  deactivate g
  activate Customer
  Customer -> g: Submit form
  deactivate Customer
  activate g
  g --> g: Process payment
  == Final redirect of customer ==
  g -> Customer: Connecting Party website redirect_url
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  activate Merchant
  group Get Final Status
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant -> Customer: Show result
  deactivate Merchant
```

(2) To implement preauth-form request see [/api/v2/preauth-form/](https://doc.payneteasy.com/integration/API_commands/api_v2_preauth-form.html.md).
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11,12) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(13) To implement callback with final status handling see [Connecting Party](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 

#### Capture Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Capture
  activate A
  end
  == Capture ==
  A -> B: api/v2/capture
  activate B
  B --> A: Order ID
  B -> B: Process Capture
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Capture can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

#### Cancel Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Preauth Transaction
  autonumber
  group Optional
  Payer -> A: Initiate Cancel
  activate A
  end
  == Cancel ==
  A -> B: api/v2/return
  activate B
  B --> A: Order ID
  B -> B: Process Cancel
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Cancel can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.

### Presta Shop

The Paynet Easy payment module for Presta Shop lets a store built on Presta Shop 1.7 and later accept card payments through Payneteasy. It plugs into the standard Presta Shop checkout as a payment method and processes Sale transactions via the Payneteasy Connecting Party API, either through a redirect (“FORM” integration) or an embedded card form (“DIRECT” integration) shown directly on the payment step.

A live example of the plugin running on a sample storefront is available here: [Presta Shop demo shop](https://prestashop17.codetime.net).

#### Source code

The plugin source code is maintained on Git Hub: [payneteasy/php-plugin-prestashop-1](https://github.com/payneteasy/php-plugin-prestashop-1).

### Receipt and message templates

#### General Introduction

Both receipt and message templates must be sent to Payneteasy support for installation.
 
Payneteasy supports receipt and message delivery to customer after each successful transaction.
 
Receipts are accessed by unique URL described below. Messages can be sent by SMS or E-mail using Connecting Party message server.
 

#### Receipt Template

Receipts can be sent only in HTML format.
 
Receipt ID can be found in status response.
 

| Integration | Production |
|--------------------------------------------------------------------------|-----------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/view-receipt/ENDPOINT-ID/RECEIPT-ID | https://gate.payneteasy.eu/paynet/view-receipt/ENDPOINT-ID/RECEIPT-ID |

##### Receipt template macros

| Field Name Macro | Description |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------|
| $!{PAYMENT_FORM_HEADER} | Name on payment form in End Point |
| $!{DATE} | Order date. |
| $!{DESCRIPTION} | Brief order description. |
| $!{AMOUNT} | Amount. |
| $!{CURRENCY} | Currency the transaction is charged in (three-letter currency code). |
| $!{PAYNET_ORDER_ID} | Payneteasy order id. |
| $!{MERCHANT_ORDER_ID} | Order ID assigned to this order by the Connecting Party. |
| $!{RRN} | Bank Receiver Registration Number. |
| $!{AUTH_CODE} | Authorization Code. |
| $!{AUTH_RESPONSE_CODE} | A two- to six-digit alphanumeric code provided by the issuer that indicates the authorization response (approval or denial). |
| $!{STATUS} | Order status. |
| $!{SKIN_VERSION} | CSS skin version. |
| $!{BIN} | Bank BIN of customer credit card number. |
| $!{LAST_FOUR_DIGITS} | Last four digits of a card. |
| $!{CARD_TYPE} | Card type. |
| $!{CARDHOLDER_NAME} | Card holder name. |
| $!{DESTINATION_BIN} | Bank BIN of destination credit card number. |
| $!{DESTINATION_LAST_FOUR_DIGITS} | Last four digits of a destination card. |
| $!{DESTINATION_CARD_TYPE} | Destination card type. |
| $!{PAYNET_PROCESSING_DATE} | Payneteasy processing date. |
| $!{ACQUIRER_PROCESSING_DATE} | Acquirer bank processing date. |
| $!{READER_PROCESSING_DATE} | Reader terminal processing date. |
| $!{TERMINAL_ID} | Terminal ID. |
| $!{EMV_ISSUER_RESPONSE} | A response code to an authorization request sent by the issuer. |
| $!{EMV_TERMINAL_AID_9F06} | Application Identifier terminal. Identifies the application as described in ISO/IEC 7816-5. |
| $!{EMV_TVR_95} | Terminal Verification Results. Status of the different functions as seen from the terminal. |
| $!{EVM_CID_9F27} | Cryptogram Information Data. Indicates the type of cryptogram and the actions to be performed by the terminal. |
| $!{EMV_APP_LABEL_50} | Application Label. Mnemonic associated with the AID according to ISO/IEC 7816-5. |
| $!{EMV_CVR_9F34} | Cardholder Verification Method (CVM) Results. Indicates the results of the last CVM performed. |
| $!{EMV_APP_CRYPTOGRAM_9f26} | Application Cryptogram. Cryptogram returned by the ICC in response of the GENERATE AC command. |
| $!{EMV_PAN_SEQUENCE_5f34} | Application Primary Account Number (PAN) Sequence Number. Identifies and differentiates cards with the same PAN. |
| $!{PIN_OR_SIGNATURE} | Ask for PIN or just have a signature. |
| $!{READER_ENTRY_MODE} | Client authentication configuration in terminal. |
| $!{HAS_SIGNATURE} | Presence of a signature (TRUE or FALSE). |
| $!{RECEIPT_ID} | Receipt ID. |
| $!{RECEIPT_URL} | URI of the current receipt. |
| $!{FUNCTIONS} | Library of functions for working with strings. |

##### Receipt template example

```html
<!DOCTYPE html>
<html>
    <body style="font-family:'tahoma';color:#1A407D;">

        <h1 style="font-weight:900;color:#7D1A40;">
            $!AMOUNT $!CURRENCY Paid
        </h1>

            Hi $!CARDHOLDER_NAME,
             
            Thank you for your payment through Payneteasy!
             
            Here are your transaction details:

            $!CARDHOLDER_NAME
             
            Transaction # : $!PAYNET_ORDER_ID
             
            Paid with $!CARD_TYPE ending with $!LAST_FOUR_DIGITS
             
            $!DATE

            The transaction will appear on your credit card statement as nymeria.

        <div style="height: 2px;background-color:#E7E7E7;margin-top:32px;margin-bottom:32px;"></div>
             
            <a style="font-family:'tahoma';color:#1A407D;" href="https://site.company_server/"><span>gate.payneteasy.eu</span></a>
            <span style="font-family:'tahoma';color:#1A407D;margin-right:16px;margin-left:16px;">Support@gate.payneteasy.eu</span>

    </body>
</html>
```

#### Message template

Messages can be sent to customer in plain text, SMS or HTML format.
 
Message server must be specified on Project or Endpoint level.
 

##### Message template macros

| Field Name Macro | Description |
|------------------------------|------------------------------------------------------------------------------------------------------------------------------|
| $!{CARDHOLDER_VALUE} | Card printed name. |
| $!{CARDHOLDER_EMAIL} | Card holder email sent in incoming API request. |
| $!{CARDHOLDER_PHONE} | Card holder phone number sent in incoming API request. |
| $!{CUSTOMER_FULL_NAME} | Customer full name sent by connecting party via input parameters. |
| $!{CUSTOMER_FIRST_NAME} | Customer first name sent by connecting party via input parameters. |
| $!{CUSTOMER_LAST_NAME} | Customer last name sent by connecting party via input parameters. |
| $!{CUSTOMER_COUNTRY_NAME} | Customer country name sent in incoming API request. |
| $!{CUSTOMER_COUNTRY_CODE} | Billing country of customer sent in incoming API request. For example, IL, RU, etc. |
| $!{CUSTOMER_STATE_NAME} | Customer state name sent by connecting party via input parameters, if there are any in customer’s country. |
| $!{CUSTOMER_STATE_CODE} | Customer state code sent by connecting party via input parameters, if there are any in customer’s country. |
| $!{CUSTOMER_CITY} | Customer city name sent in incoming API request. |
| $!{CUSTOMER_ZIP_CODE} | Customer’s ZIP code. |
| $!{CUSTOMER_ADDRESS1} | Customer address sent in incoming API request. |
| $!{CUSTOMER_ADDRESS2} | Customer address sent in incoming API request, if the additional address was required. |
| $!{AMOUNT} | Amount. |
| $!{GATEDESCRIPTOR} | Gate descriptor, specified in payment gate. |
| $!{ORDERDESCRIPTION} | Order description. |
| $!{CURRENCY} | Currency the transaction is charged in (three-letter currency code). |
| $!{CARD_NUMBER} | 6 + 4 masked card number |
| $!{BIN} | Bank BIN of customer credit card number. |
| $!{LAST_FOUR_DIGITS} | Last four digits of a card. |
| $!{CARD_TYPE} | Card type. |
| $!{PAYNET_ORDER_ID} | Payneteasy order id. |
| $!{MERCHANT_ORDER_ID} | Order ID assigned to this order by the Connecting Party. |
| $!{CREATED_DATE} | Transaction creation date in Payneteasy. |
| $!{CREATED_YEAR} | Transaction creation year in Payneteasy |
| $!{CREATED_MONTH} | Transaction creation month in Payneteasy |
| $!{CREATED_DAY} | Transaction creation day in Payneteasy |
| $!{MERCHANT} | End point display name. |
| $!{MERCHANT_NAME} | Connecting Party display name. |
| $!{MERCHANT_EMAIL} | Connecting Party email. |
| $!{ENDPOINT_ID} | End point ID. |
| $!{PAYMENT_FORM_NAME} | Name on payment form in End Point. |
| $!{RRN} | Bank Receiver Registration Number. |
| $!{APPROVAL_CODE} | Verification code needed to authorize a payment |
| $!{AUTH_RESPONSE_CODE} | A two- to six-digit alphanumeric code provided by the issuer that indicates the authorization response (approval or denial). |
| $!{STATUS} | Status of the order. |
| $!{PAYNET_PROCESSING_DATE} | Payneteasy processing date (year, month, day and time in MSK timezone). |
| $!{ACQUIRER_PROCESSING_DATE} | Acquirer bank processing date (year, month, day and time in MSK timezone). |
| $!{READER_PROCESSING_DATE} | Reader terminal processing date (year, month, day and time in MSK timezone). |
| $!{TERMINAL_ID} | Terminal ID. |
| $!{EMV_ISSUER_RESPONSE} | A response code to an authorization request sent by the issuer. |
| $!{EMV_TVR_95} | Terminal Verification Results. Status of the different functions as seen from the terminal. |
| $!{EVM_CID_9F27} | Cryptogram Information Data. Indicates the type of cryptogram and the actions to be performed by the terminal. |
| $!{EMV_APP_LABEL_50} | Application Label. Mnemonic associated with the AID according to ISO/IEC 7816-5. |
| $!{EMV_CVR_9F34} | Cardholder Verification Method (CVM) Results. Indicates the results of the last CVM performed. |
| $!{EMV_APP_CRYPTOGRAM_9f26} | Application Cryptogram. Cryptogram returned by the ICC in response of the GENERATE AC command. |
| $!{EMV_PAN_SEQUENCE_5f34} | Application Primary Account Number (PAN) Sequence Number. Identifies and differentiates cards with the same PAN. |
| $!{PIN_OR_SIGNATURE} | Ask for PIN or just have a signature. |
| $!{READER_ENTRY_MODE} | Client authentication configuration in terminal. |
| $!{HAS_SIGNATURE} | Presence of a signature (TRUE or FALSE). |
| $!{RECEIPT_ID} | Receipt ID. |
| $!{RECEIPT_URI} | URN of the current receipt (/view-receipt/ENDPOINT-ID/RECEIPT-ID). |
| $!{PURPOSE} | Any additional information sent by Connecting Party. |
| $!{MERCHANT_DATA} | Any additional information for this transaction which may be useful in Connecting Party’s external systems. |
| $!{ENDPOINT_SEQUENCE_VALUE} | Used when there is a sequence of end points, increasing by one in numerical format. |

##### Message template examples

Plain text and SMS template example:
 
```http
$!{AMOUNT} $!{CURRENCY} Paid
Hi $!{CARDHOLDER_VALUE},
Thank you for your payment through Payneteasy!
Here are your transaction details:
$!{CARDHOLDER_VALUE}
Transaction # : $!{PAYNET_ORDER_ID}
Paid with $!{CARD_TYPE} ending with $!{LAST_FOUR_DIGITS}
$!{CREATED_DATE}
The transaction will appear on your credit card statement as nymeria.
```

HTML template example:
 
```html
<!DOCTYPE html>
<html>
    <body style="font-family:'tahoma';color:#1A407D;">

        <h1 style="font-weight:900;color:#7D1A40;">
            $!AMOUNT $!CURRENCY Paid
        </h1>

            Hi $!CARDHOLDER_VALUE,
             
            Thank you for your payment through Payneteasy!
             
            Here are your transaction details:

            $!CARDHOLDER_VALUE
             
            Transaction # : $!PAYNET_ORDER_ID
             
            Paid with $!CARD_TYPE ending with $!LAST_FOUR_DIGITS
             
            $!CREATED_DATE

            The transaction will appear on your credit card statement as nymeria.

        <div style="height: 2px;background-color:#E7E7E7;margin-top:32px;margin-bottom:32px;"></div>
             
            <a style="font-family:'tahoma';color:#1A407D;" href="https://site.company_server/"><span>gate.payneteasy.eu</span></a>
            <span style="font-family:'tahoma';color:#1A407D;margin-right:16px;margin-left:16px;">Support@gate.payneteasy.eu</span>

    </body>
</html>
```

### Recurring Payments Service

#### Introduction

Recurring (also Recurrent) transaction is a type of bank payment, where charges are applied to a cardholder in predetermined intervals for services or goods of an ongoing nature (memberships, subscriptions, loan payments). Prior to the charges, card must be registered in Payment Gateway. Recurring Payments Service enables automatic processing of payments on a regular schedule, such as daily, weekly, monthly, or annually. With this service, Payers can set up their payment details once, and the system will automatically charge their credit card or bank account at the specified intervals. The Connecting Party is not required to specify the recurring schedule on Payment Gateway side: the recurring payment requests can also be initiated manually according to Connecting Party internal schedule, business model or Payer’s request. To view and manage recurring payments service from UI, contact support manager.
 

#### Direct Recurring Payments Flow

This flow implies that Connecting Party has PCI DSS certificate and is able to work with cardholder data.
 
```plantuml
@startuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Subscribe for\nrecurring payments
== Create recurring payment ==
activate A
A -> B: /api/v4/create-recurring-payment/
activate B
B -> B: Create recurring\npayment profile
B --> A: Recurring Payment ID
deactivate B
Payer <-- A: Recurring payment\nis registered
deactivate A
group If recurring schedule is set
...                                       According to schedule...
B -> B: Process scheduled\nrecurring transaction
activate B
A <- B: Callback with Final Status
activate A
A --> B: HTTP 200
deactivate B
Payer <-- A: Notify Payer
deactivate A
end
group Optional
== Process recurring payment ==
A -> B: v4/process-recurring-payment/\nwith Recurring Payment ID
activate B
activate A
A <-- B: Creating recurring transaction
B -> B: Process recurring\ntransaction
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
Payer <-- A: Notify Payer
deactivate A
end
group Optional
== Update recurring payment ==
A -> B: v4/update-recurring-payment/\nwith Recurring Payment ID
activate B
activate A
A <-- B: Updating recurring payment
deactivate A
B -> B: Update recurring\npayment profile
group If recurring schedule is set
deactivate B
...                                       According to schedule...
B -> B: Process scheduled\nrecurring transaction
activate B
A <- B: Callback with Final Status
activate A
A --> B: HTTP 200
deactivate B
A --> Payer: Notify Payer
deactivate A
end
end
@enduml
```

(2) To create recurring payment see [/api/v4/create-recurring-payment/](https://doc.payneteasy.com/integration/API_commands/api_v4_create-recurring-payment.html.md). To create recurring payments for multiple Payers in a single request with CSV data see [/api/v4/create-recurring-payments/](https://doc.payneteasy.com/integration/API_commands/api_v4_create-recurring-payments.html.md).
 
(7, 8, 13, 14, 20, 21) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(10) To process recurring payment see [/api/v4/process-recurring-payment/](https://doc.payneteasy.com/integration/API_commands/api_v4_process-recurring-payment.html.md). To process recurring payments for multiple Payers in a single request with CSV data see [/api/v4/process-recurring-payments/](https://doc.payneteasy.com/integration/API_commands/api_v4_process-recurring-payments.html.md).
 
(16)To update recurring payment see [/api/v4/update-recurring-payment/](https://doc.payneteasy.com/integration/API_commands/api_v4_update-recurring-payment.html.md). To update recurring payments for multiple Payers in a single request with CSV data see [/api/v4/update-recurring-payments/](https://doc.payneteasy.com/integration/API_commands/api_v4_update-recurring-payments.html.md).
 
(6, 19) According to schedule means that if the schedule is set, the system will automatically process transactions at the specified intervals, update the profile and notify the Connecting Party of each completed transaction. If the schedule is not set, client can be charged only manually via UI or API call. The schedule can be changed later (see step 16).
 
(9, 15, 22) Payment results can be sent by Connecting Party based on internal business model or Payer’s request.
 

#### Recurring Payments With Initial Transaction Flow

In contrast to Direct Recurring Payments Flow, in Recurring Payments With Initial Transaction Flow the initial payment must be performed to verify and authorize the Payer’s card. Any transaction type that contains payment data will be suitable for this purpose: sale, preauth, transfer, etc. That transaction must be previously processed in Payment Gateway and have final status.
 
This flow doesn’t contain cardholder data in communication between Payer and Connecting Party, as well as between Connecting Party and Payment Gateway, therefore, PCI DSS certification for Connecting Party is not required.
 
```plantuml
@startuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
hnote over Payer,B : Initial payment
Payer -> A: Subscribe for\nrecurring payments
activate Payer
activate A
== Card registration ==
A -> B: Initiate card registration\nvia v4/create-card-ref
activate B
B -> B: Create recurring\npayment profile
B --> A: Return Recurring Payment ID
deactivate B
Payer <-- A: Recurring payment\nis registered
deactivate A
deactivate Payer
group Optional
== Process recurring payment ==
A -> B: v4/process-recurring-payment/\nwith Recurring Payment ID
activate B
activate A
A <-- B: Creating recurring transaction
B -> B: Process recurring\ntransaction
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
Payer <-- A: Notify Payer
deactivate A
end
group Optional
== Update recurring payment ==
A -> B: v4/update-recurring-payment/\nwith Recurring Payment ID
activate B
activate A
A <-- B: Updating recurring payment
deactivate A
B -> B: Update recurring\npayment profile
group If recurring schedule is set
deactivate B
...                                       According to schedule...
B -> B: Process scheduled\nrecurring transaction
activate B
A <- B: Callback with Final Status
activate A
A --> B: HTTP 200
deactivate B
A --> Payer: Notify Payer
deactivate A
end
end
@enduml
```

Discuss with support manager which API Use-Case will be most suitable for initial payment.
 
(2) To initiate Card registration request and get Recurring Payment ID see [api/v4/create-card-ref](https://doc.payneteasy.com/integration/API_commands/api_v4_create-card-ref.html.md).
 
(9, 10, 16, 17) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(6) To process recurring payment see [/api/v4/process-recurring-payment/](https://doc.payneteasy.com/integration/API_commands/api_v4_process-recurring-payment.html.md). To process recurring payments for multiple Payers in a single request with CSV data see [/api/v4/process-recurring-payments/](https://doc.payneteasy.com/integration/API_commands/api_v4_process-recurring-payments.html.md).
 
(12) To update recurring payment see [/api/v4/update-recurring-payment/](https://doc.payneteasy.com/integration/API_commands/api_v4_update-recurring-payment.html.md). To update recurring payments for multiple Payers in a single request with CSV data see [/api/v4/update-recurring-payments/](https://doc.payneteasy.com/integration/API_commands/api_v4_update-recurring-payments.html.md).
 
(15) According to schedule means that if the schedule is set, the system will automatically process transactions at the specified intervals, update the profile and notify the Connecting Party of each completed transaction. If the schedule is not set, client can be charged only manually via UI or API call. The schedule can be changed later (see step 12).
 
(11, 18) Payment results can be sent by Connecting Party based on internal business model or Payer’s request.

### Recurring Preauth, Capture and Cancel

#### Introduction

Preauthorization 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. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Recurring (Rebill) Preauth is a type of transaction in which funds are debited from the Payer’s side to the Connecting Party’s bank account with previously saved cardholder data. Recurring preauth transaction can be initiated manually on Payer’s behalf (this simplifies the payment process for the Payer) or automatically at certain intervals by Connecting Party (i.e. as a subscription model). Payer does not have to re-enter card information, Connecting Party uses Card reference ID to authorize payment. The necessity of Payer’s 3DS check and submit of card security code (CVC, CVV, etc) for recurring preauth transactions is determined by bank account settings and related to Connecting Party business type.
 
 
[Capture](#capture-preauth) is a transaction followed after preauth which deducts the locked amount from Payer’s card.
 
[Cancel](#cancel-preauth) is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card.
 
 
Recurring payments are made in three steps:
 
1. Initial payment – make initial payment to verify and authorize the Payer’s card. Any transaction type with present cardholder data will work as initial payment - sale, preauth, transfer, etc.
 
2. Card registration – get Card reference ID and register Payer’s card in Payer’s profile. Card registration requires initial payment to be in [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md).
 
3. Recurring preauth – process recurring preauth transaction using Card reference ID.
 

#### Recurring Preauth Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payment Gateway" as B
autonumber
hnote over Payer,B : Initial payment
== Card registration ==
A -> B: api/v2/create-card-ref/
activate B
activate A
B --> A: Return Card ref ID
deactivate B
A -> A: Save Card ref ID to Payer's profile
deactivate A
== Get Card Info ==
group Optional
A -> B: api/v2/get-card-info/
activate A
activate B
B --> A: Return Card info
deactivate A
deactivate B
end
== Recurring Preauth ==
group Optional
Payer -> A: Initiate Recurring Preauth
activate A
activate Payer
end
A -> A: Get Card ref ID from Payer's profile
group Optional
A -> Payer: Request CVV from Payer
Payer --> A: Submit CVV
end
A -> B: api/v2/make-rebill-preauth/
activate B
B --> A: Response with Order ID
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
group Optional
A --> Payer: Show result
deactivate Payer
deactivate A
end
```

> **Note:** Initial payment transaction type and implementation depends on Connecting Party business model. Please contact Payneteasy support team to get relevant integration Use-Case for initial payment.

(1) To implement Card registration and get Card reference ID see [/api/v2/create-card-ref/](https://doc.payneteasy.com/integration/API_commands/api_v2_create-card-ref.html.md).
 
(4) To implement Card information request by Card reference ID see [/api/v2/get-card-info/](https://doc.payneteasy.com/integration/API_commands/api_v2_get-card-info.html.md). The contents of response to this request can be used to show information about previously used card to Payer or to update Connecting Party database. This request can be made anytime if Connecting Party has Card reference ID.
 
(6) Recurring payment can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(8, 9) Connecting Party sends request to the Payer to submit the CVV/CVC (Card Verification Value/Code), if it is required for selected processing channel.
 
(10) To initiate recurring preauth transaction see [/api/v2/make-rebill-preauth/](https://doc.payneteasy.com/integration/API_commands/api_v2_make-rebill-preauth.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#simplified-authentication-flow). See [3DS Decision Making Schema](#ds-2x-decision-making-schema-preauth).
 
(12) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(14) To implement order status see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(16) Results of operation can be sent by Connecting Party based on internal business model or Payer’s request.
 

#### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#simplified-authentication-flow).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-2x-decision-making-schema-preauth) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

##### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. Steps 1-2-(5)-6 of [3DS decision making schema](https://doc.payneteasy.com/integration/server_to_server_sale.html.md) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. Transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).
 

#### Capture Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payment Gateway" as B
hnote over Payer,B : Successful Preauth Transaction
autonumber
== Capture ==
group Optional
Payer -> A: Initiate Capture
activate Payer
activate A
end
A -> B: api/v2/capture
activate B
B --> A: Order ID
B -> B: Process Capture
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate Payer
deactivate A
end
```

(1) Capture can be initiated by Connecting Party based on internal business process or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

#### Cancel Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payment Gateway" as B
hnote over Payer,B : Successful Preauth Transaction
autonumber
== Cancel ==
group Optional
Payer -> A: Initiate Cancel
activate Payer
activate A
end
A -> B: api/v2/return
activate B
B --> A: Order ID
B -> B: Process Cancel
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate Payer
deactivate A
end
```

(1) Cancel can be initiated by Connecting Party based on internal business process or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.

### Recurring Sale

#### Introduction

Recurring (Rebill) Sale is a type of transaction in which funds are debited from the Payer’s side to the Connecting Party’s bank account with previously saved cardholder data. Recurring sale transaction can be initiated manually on Payer’s behalf (this simplifies the payment process for the Payer) or automatically at certain intervals by Connecting Party (i.e. as a subscription model). Payer does not have to re-enter card information, Connecting Party uses Card reference ID to authorize payment. The necessity of Payer’s 3DS check and submit of card security code (CVC, CVV, etc) for recurring sale transactions is determined by bank account settings and related to Connecting Party business type.
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Recurring payments are made in three steps:
 
1. Initial payment – make initial payment to verify and authorize the Payer’s card. Any transaction type with present cardholder data will work as initial payment - sale, preauth, transfer, etc.
 
2. Card registration – get Card reference ID and register Payer’s card in Payer’s profile. Card registration requires initial payment to be in [final status](https://doc.payneteasy.com/integration/reference/statuses.html.md).
 
3. Recurring sale – process recurring sale transaction using Card reference ID.
 

#### Recurring Sale Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payment Gateway" as B
autonumber
hnote over Payer,B : Initial payment
== Card registration ==
A -> B: api/v2/create-card-ref/
activate B
activate A
B --> A: Return Card ref ID
deactivate B
A -> A: Save Card ref ID to Payer's profile
deactivate A
== Get Card Info ==
group Optional
A -> B: api/v2/get-card-info/
activate A
activate B
B --> A: Return Card info
deactivate A
deactivate B
end
== Recurring Sale ==
group Optional
Payer -> A: Initiate Recurring Sale
activate A
activate Payer
end
A -> A: Get Card ref ID from Payer's profile
group Optional
A -> Payer: Request CVV from Payer
Payer --> A: Submit CVV
end
A -> B: api/v2/make-rebill-sale/
activate B
B --> A: Response with Order ID
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
group Optional
A --> Payer: Show result
deactivate Payer
deactivate A
end
```

> **Note:** Initial payment transaction type and implementation depends on Connecting Party business model. Please contact Payneteasy support team to get relevant integration Use-Case for initial payment.

(1) To implement Card registration and get Card reference ID see [/api/v2/create-card-ref/](https://doc.payneteasy.com/integration/API_commands/api_v2_create-card-ref.html.md).
 
(4) To implement Card information request by Card reference ID see [/api/v2/get-card-info/](https://doc.payneteasy.com/integration/API_commands/api_v2_get-card-info.html.md). The contents of response to this request can be used to show information about previously used card to Payer or to update Connecting Party database. This request can be made anytime if Connecting Party has Card reference ID.
 
(6) Recurring payment can be initiated by Connecting Party based on internal business model or Payer’s request.
 
(8, 9) Connecting Party sends request to the Payer to submit the CVV/CVC (Card Verification Value/Code), if it is required for selected processing channel.
 
(10) To initiate recurring sale transaction see [/api/v2/make-rebill-sale/](https://doc.payneteasy.com/integration/API_commands/api_v2_make-rebill-sale.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#recurring-sale-simplified-authentication-flow). See [3DS Decision Making Schema](#ds-2x-decision-making-schema-sale).
 
(12) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(14) To implement order status see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(16) Results of operation can be sent by Connecting Party based on internal business model or Payer’s request.
 

##### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#recurring-sale-simplified-authentication-flow).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-2x-decision-making-schema-sale) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

###### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. Steps 1-2-(5)-6 of [3DS decision making schema](https://doc.payneteasy.com/integration/server_to_server_sale.html.md) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. Transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

###### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).

### Reference

### Reports for Integration

#### Remote transactions report

##### Overview

Remote transactions report provide an option to get complete information about transactions with their statuses for reconciliation, data integrity checks and further analysis.
 
Connecting Party is able to get a transaction report via Payment Gateway API.
 

##### Remote Transactions Report Flow

```plantuml
  @startuml
  autonumber
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  participant "Connecting Party" as User
  participant "Payment Gateway" as Merchant
  User -> Merchant: GET request to download transaction report\n/services/transaction-report
  activate User
  activate Merchant
  Merchant --> Merchant: Report is created
  Merchant --> User: Send remote transaction report
  deactivate Merchant
  deactivate User
  @enduml
```

(1) To send GET request to download remote transaction report see [/services/transaction-report](https://doc.payneteasy.com/integration/API_commands/services_transaction-report.html.md).
 
(2) Remote transaction report is generated based on applied filters.
 
(3) Prepared report is sent to Connecting Party.
 

#### Custom reports

##### Overview

Custom reports provide an option to get customized information from Payneteasy system to meet the specific business needs. Custom report content and format must be requested from Payment Gateway representatives.
 
Connecting Party is able to get a custom report via Payment Gateway API.
 

##### Custom Report Flow

```plantuml
  @startuml
  autonumber
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  participant "Connecting Party" as User
  participant "Payment Gateway" as Merchant
  User -> Merchant: GET request to download custom report\n/services/v2/rpt-engine
  activate User
  activate Merchant
  Merchant --> Merchant: Report is created
  Merchant --> User: Send custom report
  deactivate Merchant
  deactivate User
  @enduml
```

(1) To send GET request to download custom report see [/services/v2/rpt-engine](https://doc.payneteasy.com/integration/API_commands/services_v2_rpt-engine.html.md).
 
(2) Custom report is prepared based on applied filters.
 
(3) Prepared report is sent to Connecting Party.

### Request Authentication Methods

### Return Transactions

#### Introduction

**Return:** Return transaction means returning money back to a Payer’s credit card or other type of account. Returned funds are not instantly displayed on Payer’s banking account, refund processing by Acquirer can take several days after it has been initiated. Return can only be processed for Sale, Preauth and Capture transactions in the final successful status. For Preauth it makes Cancel transaction, for Capture and Sale – Reversal. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).
 
**Void:** Void transaction sometimes can be used instead of Refund transaction to return money back to Payer’s account. Void request excludes transaction from Acquirer’s clearing list. The transaction can only be voided if it has been authorized but not settled yet. If clearing already happened or Void is not supported, it’s only possible to return funds to Payer’s account with Refund transaction.
 
Void can only be processed for Sale and Capture transactions in the final successful status, Void request makes Void transaction. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md). Void might not be supported in most cases, ask support manager for details.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Return Transaction Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Sale, Preauth or Capture transaction
  autonumber
  group Optional
  Payer -> A: Initiate Return
  activate A
  end
  == Return ==
  A -> B: api/v2/return
  activate B
  B --> A: Order ID
  B -> B: Process Return
  group Get Final Status
  == Receive Connecting Party Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Return can be initiated by Connecting Party based on internal business process or by Payer’s request.
 
(2) To implement return request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Return will be sent only if notify_url was provided in initial transaction request or additional callback URL for Return transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Return will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business process or Payer’s request.
 

#### Void Transaction Flow

```plantuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 1
  skinparam maxmessagesize 100
  skinparam sequenceParticipant underline
  actor Payer
  participant "Connecting party" as A
  participant "Payment Gateway" as B
  hnote over A,B : Successful Sale or Capture transaction
  autonumber
  group Optional
  Payer -> A: Initiate Void
  activate A
  end
  == Void ==
  A -> B: api/v2/void
  activate B
  B --> A: Order ID
  B -> B: Process Void
  group Get Final Status
  == Receive Callback ==
  A <- B: Callback with Final Status
  A --> B: HTTP 200
  deactivate B
  == Order Status Request ==
  A -> B: Get Status by Order ID api/v2/status
  activate B
  B --> A: Response with Status, Order-stage
  deactivate B
  end
  group Optional
  A --> Payer: Final Status
  deactivate A
  end
```

(1) Void can be initiated by Connecting Party based on internal business process or by Payer’s request.
 
(2) To implement void request see [/api/v2/void/](https://doc.payneteasy.com/integration/API_commands/api_v2_void.html.md).
 
(5) Callback for Void will be sent only if notify_url was provided in initial transaction request or additional callback URL for Void transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Void will not be sent. To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business process or Payer’s request.

### Sale Form

#### Introduction

Sale is a type of transaction, in which Payer receives goods or services from Connecting Party in exchange for money or other assets. Sale Form integration allows Connecting Party to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted payment form in PCI DSS certified environment.
 
All forms can be customized. Follow the [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) reference to see examples and macros of [Payment Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Prefilled Cardholder Data in Payment Page](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Wait Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) and [Finish Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md).
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Sale Form Flow

```plantuml
  @startuml
  skinparam roundcorner 20
  skinparam sequenceArrowThickness 2
  skinparam ParticipantPadding 30
  actor Payer as Customer
  participant "Connecting Party\nwebsite" as Merchant
  participant "Payment Gateway" as g
  autonumber
  Customer -> Merchant: Checkout
  activate Merchant
  == Purchase payment request ==
  Merchant -> g: api/v2/sale-form
  activate g
  g --> Merchant: Redirect-url, orderId
  deactivate g
  Merchant -> Customer: Provide redirect-url \nto payer’s browser
  deactivate Merchant
  activate Customer
  Customer -> g: GET redirect-url
  deactivate Customer
  activate g
  g --> Customer: Payment Form
  deactivate g
  activate Customer
  Customer -> g: Submit form
  deactivate Customer
  activate g
  g --> g: Process payment
  == Final redirect of customer ==
  g -> Customer: Connecting Party website redirect_url
  activate Customer
  Customer -> Merchant: POST redirect_url\nstatus, orderid
  deactivate Customer
  activate Merchant
  group Get Final Status
  == Receive Connecting Party Callback ==
  Merchant <- g: Сallback with final status
  g <-- Merchant: HTTP 200
  deactivate g
  == Order Status Request ==
  Merchant -> g: api/v2/status
  activate g
  g --> Merchant: Response \nstatus, order-stage
  deactivate g
  end
  Merchant --> Customer: Show result
  deactivate Merchant
  @enduml
```

(2) To implement sale-form request see [/api/v2/sale-form/](https://doc.payneteasy.com/integration/API_commands/api_v2_sale-form.html.md).
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11,12) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(13) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### Server-to-Server Account Verification

#### Introduction

Account verification is a non-financial transaction, which allows to validate Payer’s card account information. This verification procedure helps to prevent potential fraudulent activity and meet industry-specific compliance obligations. In this Use-Case, Payer’s cardholder data is transferred directly in initial request from Connecting Party to Payment Gateway.
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Account Verification Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/account-verification/
activate B
B --> A: Order ID
B -> B: Process\nAccount Verification
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement account verification request see [/api/v2/account-verification/](https://doc.payneteasy.com/integration/API_commands/api_v2_account-verification.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#account-verification-simplified-authentication-flow). See [3DS Decision Making Schema](#ds-server-to-server-account-verification-reference).
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#account-verification-simplified-authentication-flow).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-server-to-server-account-verification-reference) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

##### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. Steps 1-2-(5)-6 of [3DS decision making schema](https://doc.payneteasy.com/integration/server_to_server_sale.html.md) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. Transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).

### Server-to-Server Payout

#### Introduction

Payout is a type of transaction which results in funds transfer from Connecting Party banking account to customer (receiver) banking account or digital wallet. Payout transaction in most cases is used for bank account funding.
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Payout Flow

```plantuml
@startuml
participant Receiver as R
participant "Connecting Party" as cp
autonumber
group Optional
R -> cp : Checkout
activate cp
end
== Payout request ==
cp -> "Payneteasy": /api/v4/payout/
activate "Payneteasy"
"Payneteasy" --> cp: Order ID
group Conditional
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
"Payneteasy" --> cp : Response\nstatus,redirect-to
cp -> R: Provide redirect URL
deactivate "Payneteasy"
deactivate cp
activate R
R -> "Payneteasy": Redirect by redirect-to
deactivate R
activate "Payneteasy"
"Payneteasy" -> R: Additional Submit Form
deactivate "Payneteasy"
activate R
R -> "Payneteasy": Submit Form
deactivate R
activate "Payneteasy"
end
"Payneteasy" --> "Payneteasy": Processing\nPayout
group Get Final Status
== Receive Connecting Party Callback ==
cp <- "Payneteasy" : Callback with Final Status
"Payneteasy" <-- cp: HTTP 200
deactivate "Payneteasy"
== Order Status request ==
cp -> "Payneteasy": Get status by Order ID\napi/v2/status
activate "Payneteasy"
"Payneteasy" --> cp : Response\nstatus,order-stage
deactivate "Payneteasy"
end
group Optional
cp --> R: Show result
deactivate cp
end
@enduml
```

(1) Payout can be initiated by Connecting Party based on internal business model or Receiver’s request.
 
(2) To implement payout transaction see [/api/v4/payout](https://doc.payneteasy.com/integration/API_commands/api_v4_payout.html.md).
 
(5) Some payout methods require the Receiver to fill the additional data on the form. The form to redirect the customer will return in status response in redirect-to parameter.
 
(8) The Receiver submits the payout form.
 
(9) The Receiver gets redirected back to Connecting Party. See [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(13) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(15) Final Status can be sent by Connecting Party based on internal business model or by Receiver’s request.

### Server-to-Server Preauth, Capture and Cancel

#### Introduction

Preauthorization 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. It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards). In this use case Server-to-server Preauth, card data is transferred directly in initiating request.
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
[Capture](#capture-server) is a transaction followed after preauth which deducts the locked amount from Payer’s card.
 
[Cancel](#cancel-server) is opposite of Capture which cancels the deduction and returns locked amount back to Payer’s card.
 

#### Preauth Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/preauth/
activate B
B --> A: Order ID
B -> B: Process\nPreauth
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement preauth request see [/api/v2/preauth/](https://doc.payneteasy.com/integration/API_commands/api_v2_preauth.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#simplified-authentication-flow-preauth). See [3DS Decision Making Schema](#ds-server-to-server-preauth-reference).
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#simplified-authentication-flow-preauth).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-server-to-server-preauth-reference) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

##### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. steps 1-2-(5)-6 of [3DS decision making schema](https://doc.payneteasy.com/integration/server_to_server_sale.html.md) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).
 

#### Capture Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payment Gateway" as B
hnote over Payer,B : Successful Preauth Transaction
autonumber
== Capture ==
group Optional
Payer -> A: Initiate Capture
activate Payer
activate A
end
A -> B: api/v2/capture
activate B
B --> A: Order ID
B -> B: Process Capture
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate Payer
deactivate A
end
```

(1) Capture can be initiated by Connecting Party based on internal business process or Payer’s request.
 
(2) To implement capture request see [/api/v2/capture/](https://doc.payneteasy.com/integration/API_commands/api_v2_capture.html.md).
 
(5) Callback for Capture will be sent only if notify_url was provided in initial transaction request or additional callback URL for Capture transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Capture will not be sent. To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.
 

#### Cancel Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 100
skinparam sequenceParticipant underline
actor Payer
participant "Connecting party" as A
participant "Payment Gateway" as B
hnote over Payer,B : Successful Preauth Transaction
autonumber
== Cancel ==
group Optional
Payer -> A: Initiate Cancel
activate Payer
activate A
end
A -> B: api/v2/return
activate B
B --> A: Order ID
B -> B: Process Cancel
group Get Final Status
== Receive Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID api/v2/status
activate B
B --> A: Response with Status, Order-stage
deactivate B
end
group Optional
A --> Payer: Final Status
deactivate Payer
deactivate A
end
```

(1) Cancel can be initiated by Connecting Party based on internal business process or Payer’s request.
 
(2) To implement cancel request see [/api/v2/return/](https://doc.payneteasy.com/integration/API_commands/api_v2_return.html.md).
 
(5) Callback for Cancel will be sent only if notify_url was provided in initial transaction request or additional callback URL for Cancel transactions is specified on the endpoint level. If server_callback_url was provided in initial transaction request, callback for Cancel will not be sent. To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(9) Final Status can be sent by Connecting Party based on internal business model or by Payer’s request.

### Server-to-Server Sale

#### Introduction

Sale is a type of transaction, in which Payer receives goods or services from Connecting Party in exchange for money or other assets. In this use case Server-to-server Sale, card data is transferred directly in initiating request.
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 

#### Sale Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 1
skinparam maxmessagesize 1200
skinparam sequenceParticipant underline
actor Payer
participant "Connecting Party" as A
participant "Payneteasy" as B
autonumber
Payer -> A: Checkout
activate A
A -> B: /api/v2/sale/
activate B
B --> A: Order ID
B -> B: Process\nSale
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Callback with Final Status
A --> B: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get Status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show result
deactivate Payer
deactivate A
```

(2) To implement sale request see [/api/v2/sale/](https://doc.payneteasy.com/integration/API_commands/api_v2_sale.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#simplified-authentication-flow-sale). See [3DS Decision Making Schema](#ds-server-to-server-sale-reference).
 
(5) To implement callback with final status handling see [Connecting Party Callback](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#simplified-authentication-flow-sale).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-server-to-server-sale-reference) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

##### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. Steps 1-2-(5)-6 of [3DS decision making schema](#ds-server-to-server-sale-reference) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. Transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).

### Server-to-Server Transfer

#### Introduction

Transfer is a type of complex transaction that allows to move funds between bank cards ([PAN](#transfer-definitions)), card tokens ([RPI](#transfer-definitions)) and Connecting Party bank account ([deposit](#transfer-definitions)).
 
 
See terms definitions (Connecting Party, 3DS Method, etc) in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Possible transfer Use-Cases:
 

| PAN to PAN | Transfer from PAN to PAN occurs when transferring funds from one bank card to another, when specifying for each card their card numbers, and not the recurring payment id. |
|----------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| PAN to RPI | Transfer from PAN to RPI occurs when funds are transferred from one bank card for which its number is indicated to another bank card for which its recurring payment id is indicated. |
| RPI to PAN | Transfer from RPI to PAN occurs when funds are transferred from one bank card for which its recurring payment id is indicated to another bank card for which its number is indicated. |
| RPI to RPI | Transfer from RPI to RPI occurs when transferring funds from one bank card to another, when specifying for each card their recurring payment id, and not the card number. |
| deposit to PAN | Transfer from deposit to PAN occurs when funds are transferred from Connecting Party account to a bank card by its number. |
| deposit to PRI | Transfer from deposit to RPI occurs when funds are transferred from Connecting Party account to a bank card by recurring payment id. |

#### Transfer Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
autonumber
actor Sender as Payer
participant "Connecting Party" as A
participant "Payment Gateway" as B

Payer -> A: Checkout
activate A
== Transfer Request ==
A -> B: api/v4/transfer
activate B
B --> A: Order ID
B -> B: Process payment
hnote over Payer,B : See 3DS Decision Making Schema
group Get Final Status
== Receive Connecting Party Callback ==
A <- B: Сallback with final status
B <-- A: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show Result
deactivate A
```

(1) Transfers between cards are initiated by Sender. Transfer from Connecting Party (deposits) are initiated by Receiver, with the same transaction flow.
 
(2) To implement transfer request see [/api/v4/transfer/](https://doc.payneteasy.com/integration/API_commands/api_v4_transfer.html.md). By default, 3DS is being initiated and performed by Payment Gateway with [Simplified authentication flow](#transfer-simplified-authentication-flow). See [3DS Decision Making Schema](#ds-server-to-server-transfer-reference). For deposit to PAN and deposit to RPI cases 3DS is not initiated (flow is [non3D](#non3d-transfer)).
 
(5) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(7) To implement order status see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 

#### 3DS Decision Making Schema

```plantuml
  
  title 3DS Decision Making Schema
    start
    : (1) Send **/api/v2/status** request\nwith orderid=**paynet-order-id**\nProcess **/api/v2/status** response;
    while ((2) Check If **status** response field equals\nto finished status values\n**status** == approved\nOR **status** == declined\nOR **status** == error\nOR **status** == unknown\nOR **status** == filtered) is (NO);
    switch ((3) **html** and **redirect-to** field is present)
    case (YES)
   #Plum :(4) Create Wait HTML Page\nwhich redirects to result page\n(3DS 2.x or 1.0.2 to be applied)\n\nSee Simplified authentication flow;
    case (NO)
  endswitch
    backward:(5) Send new\n**/api/v2/status** request\nProcess\n**/api/v2/status** response;
    endwhile (YES)
    :(6) Show result page to the Payer;
    stop
    legend left
    =Legend
    | Color | Implementation responsibility |
    |<#Turquoise>| Connecting party |
    |<#Plum>| Connecting and other party |
    | | Other Party |
    endlegend
```

Connecting party has to implement all steps marked in green and purple. Below are the description for steps which reference specific API commands according to the step ID:

(1) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.
 
(4) If html and redirect-to fields are present, see [Simplified authentication flow with html page](#transfer-simplified-authentication-flow).
 
(5) The same as point (1).
 

> **Note:** The [3DS decision making schema](#ds-server-to-server-transfer-reference) is showcasing 3DS being initiated and performed by Payment Gateway. For other 3DS implementation scenarios, please see [3DS Overview](https://doc.payneteasy.com/integration/reference/3ds_overview.html.md) and contact support manager.

##### Non3D Flow

Sale transaction should be considered as non3D (no 3DS authentication) if all conditions are met:

1. Steps 1-2-(5)-6 of [3DS decision making schema](https://doc.payneteasy.com/integration/server_to_server_sale.html.md) were followed.
 
2. tds_status, html and redirect-to parameters were not present.
 
3. Transaction received final status (approved, declined, error, filtered).
 

> **Note:** Please note that transaction status “unknown” might appear for both 3DS and non3D transactions. See details in [Statuses](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).

##### Simplified Authentication Flow

```plantuml

title Simplified Authentication Flow
start
#Turquoise:(1) Send **/api/v2/status/** API request;
#Turquoise:(2) Process **/api/v2/status/** response.
Gather:
**html** parameter;
fork
#Turquoise:(3)Gather **html** parameter;
#Turquoise:(4) Return content from **html** parameter to the Payer's browser as is;
forkagain
#Turquoise:(5)Gather **redirect-to** parameter;
#Turquoise:(6)Redirect Payer to redirect URL;
endfork
:(7) Payer's browser gets redirected to ACS and Payer passes either 3DS 1.0.2 or 3DS 2.X flow.;
:(8) Payer's browser gets redirected back to **redirect_url** provided in the initial **api/v2/sale/** request.;
#Turquoise:(9) Process Payer's Browser final redirect to **redirect_url**.;
#Turquoise:(10) Return Wait HTML Page to the Payer's browser;
fork
note left
        **Wait HTML Page** lifecycle
end note
repeat
#Turquoise: (11) Request Connecting Party Server on the status of the transaction;
#Turquoise: (12) Process transaction status;
repeat while ((13) Received finished status\n(approved, declined, error, filtered or unknown)?) is (no)
-> (yes);
#Turquoise:(14) Redirect Payer's browser to the result page;
fork again
note left
        **Connecting Party Server** lifecycle
end note
#Turquoise:(15) Send **/api/v2/status/** API request;
#Turquoise:(16) Process **/api/v2/status/** response \nand follow **3DS Decision Making Schema** to analyze status response;
end fork
stop
legend left
=Legend
| Color | Implementation responsibility |
|<#Turquoise>| Connecting party |
| | Other Party |
endlegend
```

(1) and (2) To implement order status request see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md).
 
(9) To implement final redirect see [Final redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(10) The HTML wait page on Connecting Party side can have custom design and should communicate with Connecting Party server as described on the diagram.
 
(15) and (16) The same as point (1) and (2).

### /services/transaction-report

#### Introduction

Remote transactions report provide an opportunity to get complete information about transactions with their statuses for verification and further analysis.
 
 
Remote transactions report is initiated through HTTPS GET request by using [URLs](#services-transaction-report-url) and the [parameters](#services-transaction-report-parameters) specified below. Use [HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|---------------------------------------------------------------------|------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet-ui/services/transaction-report | https://gate.payneteasy.eu/paynet-ui/services/transaction-report |

#### Request Parameters

| Parameter Name | Mandatory | Description |
|---------------------|-------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| created From Date | Yes | Filters transactions on creation date. Must be in the following format: YYYY-MM-DD HH:MM:SS. |
| created To Date | Yes | Filters transactions on creation date. Must be in the following format: YYYY-MM-DD HH:MM:SS. |
| bank From Date | No | Filters transactions on date when transaction was uploaded to bank. Must be in the following format: YYYY-MM-DD HH:MM:SS. |
| bank To Date | No | Filters transactions on date when transaction was uploaded to bank. Must be in the following format: YYYY-MM-DD HH:MM:SS. |
| transaction Types | No | Comma-separated list of transaction types to return. If this parameter is omitted, transactions of all types. Following types are recognized: sale, reversal, preauth, capture, cancel, transfer, payout, fraud, chargeback, retrieval, dispute, refund. |
| transaction Statuses | No | Comma-separated list of transaction statuses to return. If this parameter is omitted, transactions in all statuses are returned. Following statuses are recognized: approved, declined, filtered. |
| endpoints | No | Comma-separated list of endpoint IDs to which returned transactions must belong. If this parameter is omitted, transactions belonging to any endpoint of Connecting Party who makes a request are returned. |

> **Note:** There are some restrictions:

\* If endpoints parameter is specified and some endpoints in the list do not belong to the Connecting Party who makes a request, or some endpoints from the list do not exist, an error message is returned.
 
\* Period specified by created From Date and created To Date parameters must not exceed 31 days in length.
 
\* Cannot make more than 10 requests per hour to this report.
 

#### Response Parameters

> **Note:** The returned report has wellformed CSV format. In accordance with [RFC 4180](https://datatracker.ietf.org/doc/html/rfc4180), fields containing line breaks (CRLF, CR, LF), double quotes, and commas are enclosed in double-quotes.

| Parameter Name | Description | Value |
|--------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| Txid | Transaction ID in Payneteasy, also referred as Order ID. | `Type`: Int `Length`: 10 |
| Created Date | Creation date in the server timezone. | `Type`: Datetime `Length`: - |
| Created Date (no time) | Creation date in the server timezone, no time. | `Type`: Datetime `Length`: - |
| Bank Date | Creation date in bank. | `Type`: Datetime `Length`: - |
| Merchant | Connecting Party’s name. | `Type`: Varchar `Length`: 128 |
| End-Point ID | Endpoint ID. | `Type`: Int `Length`: 10 |
| End-Point Name | Endpoint Name. | `Type`: Varchar `Length`: 128 |
| Project ID | Connecting Party’s project ID. | `Type`: Int `Length`: 10 |
| Project name | Name of the project. | `Type`: Varchar `Length`: 128 |
| Currency | Transaction currency. | `Type`: Varchar `Length`: 3 |
| Site URL | Domain name of the site. | `Type`: Varchar `Length`: 100 |
| Card type | Card type of international payment systems. | `Type`: Varchar `Length`: 32 |
| Ip | IP address. | `Type`: Varchar `Length`: 128 |
| Type | Transaction type. | `Type`: Varchar `Length`: 32 |
| Status | Transaction status. | `Type`: Varchar `Length`: 32 |
| Error Number | Error code. | `Type`: Int `Length`: 10 |
| Error Description | Error Description. | `Type`: Varchar `Length`: 256 |
| Reason code | Reason code (if information is available). | `Type`: Varchar `Length`: 16 |
| Reason | Reason (if information is available). | `Type`: Varchar `Length`: 256 |
| Comment | Comment (if information is available). | `Type`: Varchar `Length`: 256 |
| Amount | Transaction amount. | `Type`: Decimal `Length`: 15,3 |
| Processor ID | Processor / acquirer transaction identification number. | `Type`: Varchar `Length`: 128 |
| Card No | Masked PAN. | `Type`: Varchar `Length`: 20 |
| Name | Card holder name. | `Type`: Varchar `Length`: 128 |
| Routing Number | Routing step ID. | `Type`: Varchar `Length`: 16 |
| Account Number | Connecting Party’s balance identification number. | `Type`: Varchar `Length`: 24 |
| Email | Customer email. | `Type`: Varchar `Length`: 128 |
| Phone | Customer phone number. | `Type`: Varchar `Length`: 128 |
| Address | Address passed by API. | `Type`: Varchar `Length`: 256 |
| Zip | Zip passed by API. | `Type`: Varchar `Length`: 32 |
| City | City passed by API. | `Type`: Varchar `Length`: 128 |
| State | State passed by API. | `Type`: Varchar `Length`: 128 |
| Country | Country passed by API. | `Type`: Varchar `Length`: 128 |
| First name | Customer first name. For transfer transactions: sender first name (if sent), or receiver first name. | `Type`: Varchar `Length`: 128 |
| Last name | Customer last name. For transfer transactions: sender last name (if sent), or receiver last name. | `Type`: Varchar `Length`: 128 |
| Order Description | Payment description passed by API. | `Type`: Varchar `Length`: 256 |
| Merchant OID | ID of transaction on Connecting Party’s side. | `Type`: Varchar `Length`: 256 |
| Auxiliary transaction merchant OID | ID of master transaction in Merchant order ID field, if there are no master transactions, it will be the same as Merchant OID field. | `Type`: Varchar `Length`: 256 |
| Reversal Amount | Refund amount. | `Type`: Decimal `Length`: 15,3 |
| Capture Amount | Transaction confirmation amount after DMS authorization. | `Type`: Decimal `Length`: 15,3 |
| Approval Code | Authorization code. | `Type`: Varchar `Length`: 10 |
| Auth credit code | Auth Credit Code is indicated as auth code when performing AFT and when performing OCT. | `Type`: Varchar `Length`: 10 |
| Auth verification value | Cardholder authentication check values. Indicated only after payment for the order and in case of appropriate permission. | `Type`: Varchar `Length`: 64 |
| Transaction XID | Electronic commercial transaction identifier. Indicated only after payment for the order and in case of appropriate permission. | `Type`: Varchar `Length`: 64 |
| Transaction RRN | RRN - Retrieval Reference Number. | `Type`: Varchar `Length`: 20 |
| Transaction ARN | ARN - Acquirers Reference Number. | `Type`: Varchar `Length`: 64 |
| Card MPI status | A separate tool for checking card participation in 3-D Secure, may be Y / N. | `Type`: Varchar `Length`: 3 |
| Electronic Commerce Indicator | ECI. | `Type`: Varchar `Length`: 3 |
| Is 3DS | A tool for checking if transaction is 3DS-validated, may be True / False. | `Type`: Varchar `Length`: 3 |
| Is enrolled | A tool for checking if transaction is enrolled, may be True / False. | `Type`: Varchar `Length`: 3 |
| Support doc Cb Reason Code | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Support doc Cb Reason Name | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Described Services/Merchandise | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| What is not as described | Dispute details. | `Type`: Varchar `Length`: 256 |
| Merchant Response | These fields are related to dispute management. | `Type`: Text `Length`: - |
| Tried to Resolve with Merchant | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Last Contact Date | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Contact Name | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Contact Method | These fields are related to dispute management. | `Type`: Varchar `Length`: 256 |
| Cb Comments | These fields are related to dispute management. | `Type`: Text `Length`: - |
| Cb Documents | These fields are related to dispute management. | `Type`: Text `Length`: - |
| Cb Additional Files | These fields are related to dispute management. | `Type`: Text `Length`: - |
| Gate ID | Gate ID. | `Type`: Int `Length`: 10 |
| Gate Name | Gate Name. | `Type`: Varchar `Length`: 128 |
| Gate descriptor | Descriptor specified on the gate. | `Type`: Varchar `Length`: 128 |
| Gate method | Gate properties. | `Type`: Varchar `Length`: 255 |
| Gate method 2 | Gate properties. | `Type`: Varchar `Length`: 255 |
| Gate business type | Gate properties. | `Type`: Varchar `Length`: 256 |
| Gate MID | Gate MID. | `Type`: Varchar `Length`: 256 |
| View Receipt URL | Parameter responsible for displaying the URL of the receipt. | `Type`: Varchar `Length`: 100 |
| Destination | The parameter passed to the Purpose field. | `Type`: Varchar `Length`: 128 |
| Client commission | Total transaction fee. | `Type`: Decimal `Length`: 15,3 |
| Destination Card No | 6 + 4 of destination card. | `Type`: Varchar `Length`: 20 |
| Destination bank | Destination card issuer. | `Type`: Varchar `Length`: 128 |
| Bank name | Issuer of source card. | `Type`: Varchar `Length`: 128 |
| DAPI IMEI | Custom string provided by Connecting Party in initial request, also used as unique device 32 symbol string identifier in DAPI. | `Type`: Varchar `Length`: 32 |
| BIN country code | ISO 3166-1 alpha-2 country code of source card issuer (determined by BIN). | `Type`: Varchar `Length`: 3 |
| BIN country | Country name of source card issuer (determined by BIN). | `Type`: Varchar `Length`: 128 |
| Destination BIN country code | ISO 3166-1 alpha-2 country code of destination card issuer (determined by BIN). | `Type`: Varchar `Length`: 3 |
| Destination BIN country name | Country name of destination card issuer (determined by BIN). | `Type`: Varchar `Length`: 128 |
| Processor | Processor Name. | `Type`: Varchar `Length`: 128 |
| Processor ID | Processor ID. | `Type`: Int `Length`: 10 |
| Processor Error Code | Processor Error Code. | `Type`: Int `Length`: 10 |
| Card Ref Id | Card reference ID obtained at [Card Registration Stage](https://doc.payneteasy.com/integration/api_v2_create-card-ref.html.md). | `Type`: Int `Length`: 10 |
| Initial tx bank date (Server TZ) | Date received from Bank on Server time zone. | `Type`: Datetime `Length`: - |
| Initial tx bank date (User TZ) | Date received from Bank on Connecting Party zone. | `Type`: Datetime `Length`: - |
| Initial tx Amount | The amount received from Connecting Party. | `Type`: Decimal `Length`: 15,3 |
| External merchant identifier | External merchant identifier. | `Type`: Varchar `Length`: 128 |
| Manager rate plan | Manager rate plan name. | `Type`: Varchar `Length`: 128 |
| Bank name attr | Bank name. | `Type`: Varchar `Length`: 128 |
| Bank branch | Bank branch name. | `Type`: Varchar `Length`: 128 |
| Account name | Bank account name. | `Type`: Varchar `Length`: 128 |
| Status change date | Date of status change. | `Type`: Datetime `Length`: - |
| Manager rate plan id | Manager rate plan id. | `Type`: Int `Length`: 10 |
| Currency for processing | Currency used for transaction. | `Type`: Varchar `Length`: 3 |
| Amount in currency for processing | Amount in currency used for transaction. | `Type`: Decimal `Length`: 15,3 |
| Capture amount in currency for processing | Capture amount in currency used for transaction. | `Type`: Decimal `Length`: 15,3 |
| Reversal amount in currency for processing | Reversal amount in currency used for transaction. | `Type`: Decimal `Length`: 15,3 |
| Currency rate for processing | Currency rate used for transaction. | `Type`: Decimal `Length`: 15,3 |
| Provider currency rate | Name of rate provider for conversion. | `Type`: Decimal `Length`: 15,3 |
| Fee in currency for processing | Fee in currency used for transaction. | `Type`: Decimal `Length`: 15,3 |
| Transaction ID | Internal ID in Payneteasy which helps to distinguish several processing attempts within one transaction (Txid). | `Type`: Varchar `Length`: 128 |
| Reseller commission | Reseller transaction fee. | `Type`: Decimal `Length`: 15,3 |
| Manager commission | Manager transaction fee. | `Type`: Decimal `Length`: 15,3 |
| Dealer commission | Dealer transaction fee. | `Type`: Decimal `Length`: 15,3 |
| Processor commission | Processor transaction fee. | `Type`: Decimal `Length`: 15,3 |
| Card expiration date | Expiration date for source card. | `Type`: Varchar `Length`: 10 |
| Destination card expiration date | Expiration date for destination card. | `Type`: Varchar `Length`: 10 |
| Last routing type | Last routing type used in balancing for this transaction. | `Type`: Varchar `Length`: 128 |
| Last routing value | Last routing value used in balancing for this transaction. | `Type`: Varchar `Length`: 128 |
| IPs region | Region of Connecting Party relative to card BIN region. For Master Card possible values are: Domestic, European (EEA), European (SEPA NON EEA), European (NON SEPA NON EEA), Interregional (Inter-European), Interregional. For Visa possible values are: Domestic, European (EEA), European (Non-EEA GB, GI), European (Non-EEA CH), European (Non-EEA AD, MC, SM, VA), Interregional (Non-EEA IL, TR), Interregional. If BIN country cannot be determined, processor region value will be: Unknown. | `Type`: Varchar `Length`: 128 |
| Processor region | Card BIN region. Possible values are: EU, NON EU. If BIN country cannot be determined, processor region value will be: Unknown. | `Type`: Varchar `Length`: 128 |
| Manager ID | Manager ID. | `Type`: Int `Length`: 10 |
| Manager name | Manager name. | `Type`: Varchar `Length`: 128 |
| Creation time | Transaction creation time in the system. | `Type`: Datetime `Length`: - |
| Customer level | Customer level in CMS. | `Type`: Varchar `Length`: 128 |
| Customer IP address country | Customer country identified by IP. | `Type`: Varchar `Length`: 2 |
| Company ID | Company ID. | `Type`: Int `Length`: 2 |
| Company Name | Company name. | `Type`: Varchar `Length`: 10 |

> **Note:** The order of parameters in transaction report might change in future releases. New parameters might be added. Please implement response handling based on parameters names, not parameters order.

#### Request Example

```text
GET /paynet-ui/services/transaction-report?createdFromDate=2023-01-01%2000%3A00%3A00&createdToDate=2023-02-30%2000%3A00%3A00&oauth_consumer_key=logic&oauth_nonce=3gbXZFl3uAn&oauth_signature_method=HMAC-SHA1&oauth_timestamp=1690546956&oauth_version=1.0 HTTP/1.1
Host: sandbox.doc2.com
User-Agent: curl/7.88.1
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="logic",oauth_timestamp="1690546956",oauth_nonce="3gbXZFl3uAn",oauth_signature_method="HMAC-SHA1",oauth_signature="G46r4h99dwB9opEYSfUsgHlJeGg%3D"
Connection: close
```

#### Success Response Example

```text
Txid;Created Date (Server TZ);Created Date (User TZ);Created Date (Server TZ, no time);Bank Date (Server TZ);Bank Date (User TZ);Merchant;End-Point ID;Project ID;Project Name;Currency;Site URL;Card type;Ip;Type;Status;Error Number;Error Description;Reason code;Reason;Comment;Amount;Processor tx ID;Card No;Name;Routing Number;Account Number;Email;Phone;Address;Zip;City;State;Country;First Name;Last Name;Order Description;Merchant OID;Auxiliary transaction merchant OID;Reversal Amount;Capture amount;Approval Code;Auth Credit Code;Auth Verification Value;Transaction XID;Transaction RRN;Transaction ARN;Card MPI Status;Electronic Commerce Indicator;Is 3D;Is Enrolled;Support doc Cb reason code;Support doc Cb reason;Described services/merchandise;What is not as described;Merchant response;Tried to resolve with merchant;Last contact date;Contact name;Contact method;Cb Comments;Cb Documents;Cb additional files;Gate ID;Gate Name;Gate Descriptor;Gate Method;Gate Method 2;Gate Business type;Gate MID;View Receipt URL;Destination;Client commission;Destination Card No;Destination bank name;Bank name;DAPI IMEI;BIN country code;BIN country;Destination BIN country code;Destination BIN country;Processor;Processor Error Code;CardRefId;Initial tx bank date (Server TZ);Initial tx bank date (User TZ);Initial tx Amount;External merchant identifier;Manager rate plan;Bank name attr;Bank branch;Account name;Status change date;Manager rate plan id;Currency for processing;Amount in currency for processing;Capture amount in currency for processing;Reversal amount in currency for processing;Currency rate for processing;Provider currency rate;Fee in currency for processing;Transaction id;Reseller commission;Manager commission;Dealer commission;Processor commission;Card expiration date;Destination card expirationDate;Last routing type;Last routing value;IPs region;Processor region;Manager ID;Manager name;Creation time;Customer level
1810032;2023-05-01T17:38:43.00;2023-05-01T17:38:43.00;01.05.2023;;;Demo merchant A;7829;2251;Test Rub Project;RUB;;MasterCard;85.132.102.1;sale;filtered;10137;Billing country blacklisted for merchant;;;;100.000;;555544XXXXXX1111;TEST HOLDER;;;j***b@brown.demo;8***01122;Red*** 1;***;***;;RUS;Jacob;Brown;Test payment;ylT2sut-hqXHxTFspRVUd9Uvcsg;ylT2sut-hqXHxTFspRVUd9Uvcsg;;;;;;;;;;;No;;;;;;;;;;;;;;3197;Test RUB;DEMO2;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/7829/b6123559-fc64-32fd-9c91-af49a92aa2b9;purpose?;0.000;;;NATIONAL BANK OF RAS AL-KHAIMAH (RAKBANK);;AE;United Arab Emirates;;;Test processor;;;2023-05-01T17:38:43.00;2023-05-01T17:38:43.00;100.000;;zrt;;;;2023-05-01T17:38:43.00;398;RUB;100.000;;;;;;1537212;0.000;0.000;0.000;0.000;203604;;route by Source Credit Card Issuer Country;OTHERS;Unknown;Unknown;76;test_manager;;
1812039;2023-05-04T19:11:29.00;2023-05-04T19:11:29.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;34.129.65.121;preauth;declined;1015;SECURE_3D_TIMEOUT;;;;5.000;;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;902B4FF5;902B4FF5;;;;;;;3,1244E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/a4b048ad-47ce-33ed-af73-68c7646cee0c;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;;2023-05-04T19:11:29.00;2023-05-04T19:11:29.00;5.000;;2% cyprus;;;;2023-05-04T19:11:29.00;582;USD;5.500;;;1.099663612901000;1.099663612901000;;1539210;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812040;2023-05-04T19:11:29.00;2023-05-04T19:11:29.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;34.129.65.121;preauth;declined;1015;SECURE_3D_TIMEOUT;;;;5.000;;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;902B4FF5;902B4FF5;;;;;;;3,12424E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/270932f6-6687-3127-a32a-2baa6eb1b3f6;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;;2023-05-04T19:11:29.00;2023-05-04T19:11:29.00;5.000;;2% cyprus;;;;2023-05-04T19:11:29.00;582;USD;5.500;;;1.099663612901000;1.099663612901000;;1539211;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812037;2023-05-04T19:11:30.00;2023-05-04T19:11:30.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;34.129.65.121;sale;declined;1015;SECURE_3D_TIMEOUT;;;;5.000;;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Rebill order description;902B4FF5;902B4FF5;;;;;;;3,12425E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/711a99be-e32f-3abe-9740-e4bda0c2d372;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;;2023-05-04T19:11:30.00;2023-05-04T19:11:30.00;5.000;;2% cyprus;;;;2023-05-04T19:11:30.00;582;USD;5.500;;;1.099663612901000;1.099663612901000;;1539212;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812038;2023-05-04T19:11:30.00;2023-05-04T19:11:30.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;34.129.65.121;sale;declined;1015;SECURE_3D_TIMEOUT;;;;5.000;;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Rebill order description;902B4FF5;902B4FF5;;;;;;;3,12454E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/52e5301a-55a7-3939-9f9c-6a0114e32c15;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;;2023-05-04T19:11:30.00;2023-05-04T19:11:30.00;5.000;;2% cyprus;;;;2023-05-04T19:11:30.00;582;USD;5.500;;;1.099663612901000;1.099663612901000;;1539213;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812041;2023-05-04T19:16:26.00;2023-05-04T19:16:26.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;65.153.12.213;sale;declined;1015;SECURE_3D_TIMEOUT;;;;10.420;;444455XXXXXX1111;TEST HOLDER;;;j***h@gmail.com;1***82043;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test Order Description;902B4FF5;902B4FF5;;;;;;;3,1243E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/06636793-308d-33eb-8a21-77f92b00cd5d;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;190926;2023-05-04T19:16:26.00;2023-05-04T19:16:26.00;10.420;;2% cyprus;;;;2023-05-04T19:16:26.00;582;USD;11.460;;;1.099663612901000;1.099663612901000;;1539214;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812042;2023-05-04T19:16:26.00;2023-05-04T19:16:26.00;04.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;65.153.12.213;sale;declined;1015;SECURE_3D_TIMEOUT;;;;10.420;;444455XXXXXX1111;TEST HOLDER;;;j***h@gmail.com;1***82043;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test Order Description;902B4FF5;902B4FF5;;;;;;;3,12453E+11;;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/d9a800f3-d915-3099-a769-01f9fcb7d356;;0.000;;;UNKNOWN;;US;United States;;;Test processor;timeout;;2023-05-04T19:16:26.00;2023-05-04T19:16:26.00;10.420;;2% cyprus;;;;2023-05-04T19:16:26.00;582;USD;11.460;;;1.099663612901000;1.099663612901000;;1539215;0.000;0.000;0.000;0.000;202401;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1812688;2023-05-05T17:18:52.00;2023-05-05T17:18:52.00;05.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;89.147.253.161;transfer;filtered;10204;Customer data validation failed (firstname, lastname, cardholder, email, phone);;;;10.420;;421070XXXXXX5721;John Doe;;;;;;;;;;;;Your order description;1;1;;;;;;;;;;;No;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/402efad3-7e4a-3497-8bd4-792a11074f7f;;0.000;423261XXXXXX1636;JPMORGAN CHASE BANK N.A.;DEMIRBANK OJSC;;AZ;Azerbaijan;US;United States;Test processor;;190924;2023-05-05T17:18:52.00;2023-05-05T17:18:52.00;10.420;;2% cyprus;;;;2023-05-05T17:18:52.00;582;EUR;10.420;;;;;;1539816;0.000;0.000;0.000;0.000;209912;;route by Customer Loyalty;NEW FOR MERCHANT;Unknown;Unknown;76;test_manager;;
1817526;2023-05-16T16:15:13.00;2023-05-16T16:15:13.00;16.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;85.132.52.251;sale;approved;;;;;;100.000;PNTEST-1817526;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1817525;100.000;;504362;502894;;;3,1367E+11;179416949;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/fdf7267b-876b-36b8-84a7-2fea7a3685e4;;2.200;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-16T16:15:13.00;2023-05-16T16:15:13.00;100.000;;2% cyprus;;;;2023-05-16T16:16:11.00;582;USD;108.740;;;1.087320537745000;1.087320537745000;;1544050;0.000;2.200;0.000;1.000;202701;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1817526;2023-05-16T16:15:16.00;2023-05-16T16:15:16.00;16.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;85.132.52.251;reversal;approved;;;;;Auto-return;100.000;1,68424E+12;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1817525;100.000;;504362;502894;;;3,13665E+11;179416949;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/fdf7267b-876b-36b8-84a7-2fea7a3685e4;;0.000;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-16T16:15:13.00;2023-05-16T16:15:13.00;100.000;;2% cyprus;;;;2023-05-16T16:16:11.00;582;USD;108.740;;;1.087320537745000;1.087320537745000;;1544051;0.000;0.000;0.000;0.000;202701;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1817526;2023-05-16T16:16:11.00;2023-05-16T16:16:11.00;16.05.2023;2023-05-16T00:00:00.00;2023-05-16T00:00:00.00;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;85.132.52.251;chargeback;approved;;;11,1;Card Recovery Bulletin;manual;100.000;1,68424E+12;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1817525;100.000;;504362;502894;;;3,13665E+11;179416949;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/fdf7267b-876b-36b8-84a7-2fea7a3685e4;;0.000;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-16T16:15:13.00;2023-05-16T16:15:13.00;100.000;;2% cyprus;;;;2023-05-16T16:16:11.00;582;USD;108.740;;;1.087320537745000;1.087320537745000;;1544053;0.000;0.000;0.000;0.000;202701;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;;
1817507;2023-05-16T16:17:24.00;2023-05-16T16:17:24.00;16.05.2023;;;Demo merchant A;9068;1712;Demo Ams EUR;EUR;;Any;85.132.52.251;sale;declined;920084;Request failed: Timer expired. User not paid. Request failed: Timer expired. User not paid.;;;;100.000;;999999XXXXXX9999;Unknown holder;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1817503;;;;;;;;;;;No;;;;;;;;;;;;;;4441;Test demo EUR;DEMO3;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/9068/7f44aae1-10fe-3f05-8271-d94f539fdf6a;;0.000;;;;;;;;;Test processor;920084;;2023-05-16T16:17:24.00;2023-05-16T16:17:24.00;100.000;;2% cyprus;;;;2023-05-16T16:17:24.00;582;EUR;100.000;;;;;;1544054;0.000;0.000;0.000;0.000;202412;;route by Source Credit Card Type;ANY_CREDIT_CARD;Unknown;Unknown;76;test_manager;;
1817527;2023-05-16T16:28:20.00;2023-05-16T16:28:20.00;16.05.2023;;;Demo merchant A;9068;1712;Demo Ams EUR;EUR;;Any;85.132.52.251;sale;declined;920084;Request failed: Timer expired. User not paid. Request failed: Timer expired. User not paid.;;;;100.000;;999999XXXXXX9999;Unknown holder;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1817525;;;;;;;;;;;No;;;;;;;;;;;;;;4441;Test demo EUR;DEMO3;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/9068/33e28fb1-6443-30a1-bac2-d5d1648e38cd;;0.000;;;;;;;;;Test processor;920084;;2023-05-16T16:28:20.00;2023-05-16T16:28:20.00;100.000;;2% cyprus;;;;2023-05-16T16:28:20.00;582;EUR;100.000;;;;;;1544078;0.000;0.000;0.000;0.000;202412;;route by Source Credit Card Type;ANY_CREDIT_CARD;Unknown;Unknown;76;test_manager;;
1824084;2023-05-26T14:44:38.00;2023-05-26T14:44:38.00;26.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;BANK WIRE;85.132.52.251;transfer;approved;;;;;;55.550;1,6851E+12;;Test full name;7812013775;4,096E+19;j***h@gmail.com;7***29876;;;;;;;;Test payment;inv9157586;inv9157586;;;829695;;;;;;;;No;;;;;;;;;;;;;;2471;B MC CC Ams EUR;AMSTERDAM;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/43b0c106-0f10-307a-99f8-b3df4823337d;;0.000;;;;;;;;;Test processor;;;2023-05-26T14:44:38.00;2023-05-26T14:44:38.00;55.550;;2% cyprus;;;;2023-05-26T14:44:38.00;582;USD;59.580;;;1.072435511772000;1.072435511772000;;1549073;0.000;0.000;0.000;0.000;0;;route by Purpose;OTHERS;Unknown;Unknown;76;test_manager;2023-05-26T14:44:12.00;
1824082;2023-05-26T15:31:23.00;2023-05-26T15:31:23.00;26.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;BANK WIRE;85.132.52.251;transfer;declined;1015;SECURE_3D_TIMEOUT;;;;55.550;;;Test ful name;7812013775;4,096E+19;j***h@gmail.com;7***29876;;;;;;;;Test payment;inv9157586;inv9157586;;;;;;;3,14622E+11;;;;Yes;;;;;;;;;;;;;;2471;B MC CC Ams EUR;AMSTERDAM;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/e5b22b51-c51a-37e3-be9c-3ea581ccf583;;0.000;;;;;;;;;Test processor;timeout;;2023-05-26T15:31:23.00;2023-05-26T15:31:23.00;55.550;;2% cyprus;;;;2023-05-26T15:31:23.00;582;USD;59.580;;;1.072435511772000;1.072435511772000;;1549088;0.000;0.000;0.000;0.000;0;;route by Purpose;OTHERS;Unknown;Unknown;76;test_manager;2023-05-26T14:42:49.00;
1824083;2023-05-26T15:31:23.00;2023-05-26T15:31:23.00;26.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;BANK WIRE;85.132.52.251;transfer;declined;1015;SECURE_3D_TIMEOUT;;;;500.000;;;Test;7812013775;4,096E+19;j***h@gmail.com;7***29876;;;;;;;;;34T43R77N;34T43R77N;;;;;;;3,14692E+11;;;;Yes;;;;;;;;;;;;;;2471;B MC CC Ams EUR;AMSTERDAM;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/b580d3c7-8ff1-3cb3-8292-87486edd18c0;;0.000;;;;;;;;;Test processor;timeout;;2023-05-26T15:31:23.00;2023-05-26T15:31:23.00;500.000;;2% cyprus;;;;2023-05-26T15:31:23.00;582;USD;536.220;;;1.072435511772000;1.072435511772000;;1549089;0.000;0.000;0.000;0.000;0;;route by Purpose;OTHERS;Unknown;Unknown;76;test_manager;2023-05-26T14:44:10.00;
1824985;2023-05-29T14:45:00.00;2023-05-29T14:45:00.00;29.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;188.253.224.81;sale;approved;;;;;;100.000;PNTEST-1824985;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1824984;;;115524;407275;;;3,1496E+11;647547344;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/3317093d-b5b3-3d09-aa9b-28e1c80166d8;;2.200;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-29T14:45:00.00;2023-05-29T14:45:00.00;100.000;;2% cyprus;;;;2023-05-29T15:07:30.00;582;USD;107.320;;;1.072435511772000;1.072435511772000;;1550036;0.000;2.200;0.000;1.000;202701;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;2023-05-29T14:40:11.00;
1824987;2023-05-29T14:56:48.00;2023-05-29T14:56:48.00;29.05.2023;;;Demo merchant A;9068;1712;Demo Ams EUR;EUR;;Any;188.253.224.81;sale;declined;920084;Request failed: Timer expired. User not paid. Request failed: Timer expired. User not paid.;;;;100.000;;999999XXXXXX9999;Unknown holder;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1824984;;;;;;;;;;;No;;;;;;;;;;;;;;4441;Test demo EUR;DEMO3;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/9068/e626abe4-52eb-3a25-ae93-19de6ca44023;;0.000;;;;;;;;;Test processor;920084;;2023-05-29T14:56:48.00;2023-05-29T14:56:48.00;100.000;;2% cyprus;;;;2023-05-29T14:56:48.00;582;EUR;100.000;;;;;;1550041;0.000;0.000;0.000;0.000;202412;;route by Source Credit Card Type;ANY_CREDIT_CARD;Unknown;Unknown;76;test_manager;2023-05-29T14:41:45.00;
1824985;2023-05-29T15:07:30.00;2023-05-29T15:07:30.00;29.05.2023;2023-05-29T00:00:00.00;2023-05-29T00:00:00.00;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;188.253.224.81;retrieval;approved;;;;;manual;100.000;PNTEST-1824985;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1824984;;;115524;407275;;;3,1496E+11;647547344;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/3317093d-b5b3-3d09-aa9b-28e1c80166d8;;0.000;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-29T14:45:00.00;2023-05-29T14:45:00.00;100.000;;2% cyprus;;;;2023-05-29T15:07:30.00;582;USD;107.320;;;1.073134088104000;1.073134088104000;;1550043;0.000;0.000;0.000;0.000;202701;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;2023-05-29T14:40:11.00;
1826965;2023-05-31T16:42:20.00;2023-05-31T16:42:20.00;31.05.2023;;;Demo merchant A;6655;1712;Demo Ams EUR;EUR;;Visa;188.253.237.101;sale;approved;;;;;;100.000;PNTEST-1826965;444455XXXXXX1111;TEST HOLDER;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1826964;;;432862;200594;;;3,15182E+11;302446749;;;Yes;;;;;;;;;;;;;;2470;A VISA CC Ams EUR;DEMO1;;;;test1;https://sandbox.payneteasy.eu/paynet/view-receipt/6655/861f0fd1-9f2e-3acf-9a05-b7f8c927eae3;;2.200;;;UNKNOWN;;US;United States;;;Test processor;;;2023-05-31T16:42:20.00;2023-05-31T16:42:20.00;100.000;;2% cyprus;;;;2023-05-31T16:42:20.00;582;USD;107.220;;;1.072140012909000;1.072140012909000;;1551928;0.000;2.200;0.000;1.000;202601;;route by Customer Loyalty;OTHERS;Unknown;Unknown;76;test_manager;2023-05-31T16:37:25.00;
1826966;2023-05-31T16:53:50.00;2023-05-31T16:53:50.00;31.05.2023;;;Demo merchant A;9068;1712;Demo Ams EUR;EUR;;Any;188.253.237.101;sale;declined;920084;Request failed: Timer expired. User not paid. Request failed: Timer expired. User not paid.;;;;100.000;;999999XXXXXX9999;Unknown holder;;;a***v@example.com;+3***12233;Wes***HX;***;Ams***en;;NLD;Firstname;Lastname;Test payment;test;1826964;;;;;;;;;;;No;;;;;;;;;;;;;;4441;Test demo EUR;DEMO3;;;;;https://sandbox.payneteasy.eu/paynet/view-receipt/9068/4e6c1674-aeb1-3d5e-bbe4-0af9c37fd95d;;0.000;;;;;;;;;Test processor;920084;;2023-05-31T16:53:50.00;2023-05-31T16:53:50.00;100.000;;2% cyprus;;;;2023-05-31T16:53:50.00;582;EUR;100.000;;;;;;1551934;0.000;0.000;0.000;0.000;202412;;route by Source Credit Card Type;ANY_CREDIT_CARD;Unknown;Unknown;76;test_manager;2023-05-31T16:38:47.00;
```

#### Fail Response Example

```text
HTTP/1.1 403
Server: server
Date: Fri, 28 Jul 2023 12:44:12 GMT
Content-Type: text/html
Content-Length: 735
Connection: close

...
<body>
    <p>Access is denied</p>
</body>
```

### /services/v2/rpt-engine

#### Introduction

Custom transactions report provide an opportunity to get customized information about transactions with their statuses for verification and further analysis.
 
 
Custom transactions report is initiated through HTTPS POST request by using [URLs](https://doc.payneteasy.com/integration/services_transaction-report.html.md) and the [parameters](#services-v2-rpt-engine-parameters) specified below. Use [HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. Report parameters are being sent via JSON.
 

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------|-------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet-ui/services/v2/rpt-engine | https://gate.payneteasy.eu/paynet-ui/services/v2/rpt-engine |

#### Request Parameters

Each custom report has a different JSON body parameters. JSON templates and supported formats for required custom reports could be provided by support managers upon request.
 

Request body example:

```text
{
    "reportIdentifier": "exampleReport",
    "reportEncode": "UTF-8",
    "reportName": "example",
    "reportCsvDelimiter": ",",
    "reportFormat": "CSV",
    "configurationReportParameters": [],
    "inputReportParameters": [
        {
            "type": "INPUT_TEXT",
            "name": "example",
            "value": "example"
        }
    ],
    "outputReportParameters": [],
    "filters": {
        "gates": [],
        "companies": [],
        "projects": [],
        "endpoints": [],
        "merchants": [],
        "processors": [],
        "managers": [],
        "resellers": [],
        "currencies": []
    }
}
```

#### Response Parameters

Each custom report has a different response body parameters. Usually it’s provided in CSV or PDF format.
 
 

> **Note:** The returned report has wellformed CSV format. In accordance with [RFC 4180](https://datatracker.ietf.org/doc/html/rfc4180), fields containing line breaks (CRLF, CR, LF), double quotes, and commas are enclosed in double-quotes.

#### Request Example

```text
POST /paynet-ui/services/v2/rpt-engine HTTP/1.1
Host: gate.doc2.com
User-Agent: curl/7.88.1
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="login",oauth_timestamp="1690553049",oauth_nonce="2lrRWDbfOoq",oauth_signature_method="HMAC-SHA1",oauth_signature="ZAi2xFUlh35DAzDYKnSbyUUGGIA%3D"
Content-Type: application/json
Content-Length: 417
Connection: close

{"reportIdentifier":"exampleReport","reportEncode":"UTF-8","reportName":"example","reportCsvDelimiter":",","reportFormat":"CSV","configurationReportParameters":[],"inputReportParameters":[{"type":"INPUT_TEXT","name":"example","value":"example"}],"outputReportParameters":[],"filters":{"gates":[],"companies":[],"projects":[],"endpoints":[],"merchants":[],"processors":[],"managers":[],"resellers":[],"currencies":[]}}
```

#### Success Response Example

```text
"Merchant_Name","Transaction_id","Merchant_OID","Created_date","Amount","Currency","Transaction_type","Order_description","Date_of_report"
"TestMerchant3","6891747","902B4FF5","2023-07-27 16:37:21","90.000","USD","Sale","Order #293927","28.07.2023"
```

#### Fail Response Example

```text
HTTP/1.1 200
Server: server
Date: Mon, 31 Jul 2023 09:49:07 GMT
Content-Type: text/plain
Content-Length: 46
Connection: close
Strict-Transport-Security: max-age=31536000

You are not authorised to perform such request
```

### SHA-1 Request Authentication Method

To generate request with SHA-1 authentication:

1. [Generate Signature](#sha1-signature-generation),
2. [Generate Request](#sha1-request-generation).

#### SHA1 Signature Generation

1. Concatenate all necessary parameters to String (also referred as a “signing string” or “signature base string”). Each API-command might have it’s own list and order of parameters to concatenate in signing string. Check it in the description of `control` parameter for the relevant API-command with SHA-1 authentication.

> **Note:** Use minimal monetary units for amount (i.e. cent, penny etc. For amount of 0.94 USD value in signing string will be 94, for 10.15 USD value in signing string will be 1015)

 For example, parameters:
   ```text
   endpointid=1111
   client_orderid=902B4FF5
   amount=10.42
   email=john.smith@gmail.com
   merchant_control=B17F59B4-A7DC-41B4-8FF9-37D986B43D20
   ```

 will be concatenated to the string:
   ```text
   1111902B4FF51042john.smith@gmail.comB17F59B4-A7DC-41B4-8FF9-37D986B43D20
   ```
2. Sign the received string using SHA-1:

 Java SHA-1 Generation Example:
   ```java
   package com.Payneteasy;

   import java.nio.charset.StandardCharsets;
   import java.security.MessageDigest;
   import java.security.NoSuchAlgorithmException;

   public class HashTextTest {

   /**
   * @param args
   * @throws NoSuchAlgorithmException
   */

      public static void main(String[] args) throws NoSuchAlgorithmException {
         System.out.println(sha1("test string to sha1"));
      }

      static String sha1(String input) throws NoSuchAlgorithmException {
         MessageDigest mDigest = MessageDigest.getInstance("SHA1");
         byte[] result = mDigest.digest(input.getBytes(StandardCharsets.UTF_8));
         StringBuilder sb = new StringBuilder();
         for (byte b : result) {
            sb.append(Integer.toString((b & 0xff) + 0x100, 16).substring(1));
         }
         return sb.toString();
      }
   }
   ```

 Java Script SHA-1 Generation Example
   ```html
   <script src="http://crypto-js.googlecode.com/svn/tags/3.1.2/build/rollups/sha1.js"></script>
   <script type="text/javascript">
      var sha1value = CryptoJS.SHA1("test string to sha1");
   </script>
   ```

 Bash + openssl SHA-1 Generation Example
   ```bash
   echo -n "test string to sha1" | openssl dgst -sha1
   ```

 After that signature will look like this:
   ```text
   c6bdd88a78834ef4b863b088827a459f039e8257
   ```

#### SHA1 Request Generation

To make request use generated signature as the value of parameter `control` in request body.

Example of Request:

```text
Request method: POST
Request URI: https://gate.payneteasy.eu/paynet/api/v2/sale/1111
Body: client_orderid=902B4FF5&order_desc=Test Order Description&first_name=John&last_name=Smith&ssn=1267&birthday=19820115&address1=100 Main st&city=Seattle&state=WA&zip_code=98102&country=US&phone=+12063582043&cell_phone=+19023384543&amount=10.42&email=john.smith@gmail.com&currency=USD&ipaddress=65.153.12.232&site_url=https://doc.payneteasy.com&credit_card_number=4538977399606732&card_printed_name=CARD HOLDER&expire_month=12&expire_year=2099&cvv2=123&purpose=user_account1&control=c6bdd88a78834ef4b863b088827a459f039e8257
```

Example of CURL Request:

```text
curl --data "
   client_orderid=902B4FF5
   &order_desc=Test Order Description
   &first_name=John
   &last_name=Smith
   &ssn=1267
   &birthday=19820115
   &address1=100 Main st
   &city=Seattle
   &state=WA
   &zip_code=98102
   &country=US
   &phone=+12063582043
   &cell_phone=+19023384543
   &amount=10.42
   &email=john.smith@gmail.com
   &currency=USD
   &ipaddress=65.153.12.232
   &site_url=https://doc.payneteasy.com
   &credit_card_number=4538977399606732
   &card_printed_name=CARD HOLDER
   &expire_month=12
   &expire_year=2099
   &cvv2=123
   &purpose=user_account1
   &control=c6bdd88a78834ef4b863b088827a459f039e8257
" https://gate.payneteasy.eu/paynet/api/v2/sale/1111
```

#### SHA1 Status signature

<script src="../../_static/js/generate_card_number.js"></script>
<script src="../../_static/js/crypto-js/sha1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../../_static/js/highlight/styles/default.css">
<script src="../../_static/js/highlight/highlight.pack.js"></script>

<script>hljs.init Highlighting On Load();</script>

<script type="text/javascript">
 $(document).ready (function(){
 $("#sha1Tab a").click (function (e){
 e.prevent Default();
 $(this).tab('show');
 });
 });
</script>

<script type="text/javascript">
 function signstatus (form) {
 var signed Text = "";
 for (var e = 0; e < form.elements.length; ++e) {
 var input = form.elements[e];
 if (input.name != null)
 if (input.name.substring(0, 5) == "sha1_")
 if (input.value != null)
 if (input.value != "")
 if (!(input.type == "checkbox" || input.type == "radio") || input.checked)
 {
 signed Text = signed Text + input.value;
 }
 }
 show Text("statussignedvalue" , signed Text);
 show Text("sha1statusvalue" , CryptoJS.SHA1 (signed Text));

 return false;
 }

 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }
</script>

<form name="status">

 
 <p></p>
 <input type="button" class="doc-button" style="font-size: 100%; padding: 2px 6px 3px 6px;" value="Sign status Request" on Click="signstatus (document.status)"/>
 <p></p>
</form>

#### SHA1 Sale signature

<script src="../../_static/js/generate_card_number.js"></script>
<script src="../../_static/js/crypto-js/sha1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../../_static/js/highlight/styles/default.css">
<script src="../../_static/js/highlight/highlight.pack.js"></script>

<script>hljs.init Highlighting On Load();</script>

<script type="text/javascript">
 $(document).ready (function(){
 $("#sha1Tab a").click (function (e){
 e.prevent Default();
 $(this).tab('show');
 });
 });
</script>

<script type="text/javascript">
 function signsale (form) {
 var amount Info = document.get Element By Id("amount Warning");
 var signed Text = "";
 for (var e = 0; e < form.elements.length; ++e) {
 var input = form.elements[e];
 if (input.name != null)
 if (input.name.substring(0, 5) == "sha1_")
 if (input.value != null)
 if (input.value != "")
 if (!(input.type == "checkbox" || input.type == "radio") || input.checked)
 {
 if (input.name == "sha1_amount"){
									 var amount To Fix = input.value \* 100;
 var fixed Amount = amount To Fix.to Fixed(0);
 if (fixed Amount != amount To Fix)
 { amount Info.innerHTML = amount Info.innerHTML.replace("​", "Possible floating point imprecision (for more information check Floating Point Math)");}
 else {amount Info.innerHTML = amount Info.innerHTML.replace("Possible floating point imprecision (for more information check Floating Point Math)", "​");}
 signed Text = signed Text + fixed Amount;}
 else
 {signed Text = signed Text + input.value;}
 }
 }
 show Text("salesignedvalue" , signed Text);
 show Text("sha1salevalue" , CryptoJS.SHA1 (signed Text));

 return false;
 }

 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }
</script>

<form name="sale">

 
 <p></p>
 <input type="button" class="doc-button" style="font-size: 100%; padding: 2px 6px 3px 6px;" value="Sign sale Request" on Click="signsale (document.sale)"/>
 <p></p>
</form>

#### SHA1 Callback signature

<script src="../../_static/js/generate_card_number.js"></script>
<script src="../../_static/js/crypto-js/sha1.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.11.3/jquery.min.js"></script>
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.5/js/bootstrap.min.js"></script>
<link rel="stylesheet" href="../../_static/js/highlight/styles/default.css">
<script src="../../_static/js/highlight/highlight.pack.js"></script>

<script>hljs.init Highlighting On Load();</script>

<script type="text/javascript">
 $(document).ready (function(){
 $("#sha1Tab a").click (function (e){
 e.prevent Default();
 $(this).tab('show');
 });
 });
</script>

<script type="text/javascript">
 function signcallback (form) {
 var signed Text = "";
 for (var e = 0; e < form.elements.length; ++e) {
 var input = form.elements[e];
 if (input.name != null)
 if (input.name.substring(0, 5) == "sha1_")
 if (input.value != null)
 if (input.value != "")
 if (!(input.type == "checkbox" || input.type == "radio") || input.checked)
 {
 signed Text = signed Text + input.value;
 }
 }
 show Text("callbacksignedvalue" , signed Text);
 show Text("sha1callbackvalue" , CryptoJS.SHA1 (signed Text));

 return false;
 }

 function show Text (element Id, text) {
 var child = document.create Text Node (text);
 var element = document.get Element By Id (element Id);
 if (element.has Child Nodes()) {
 element.replace Child (child, element.first Child);
 } else {
 element.append Child (child);
 }
 }
</script>

<form name="callback">

 
 <p></p>
 <input type="button" class="doc-button" style="font-size: 100%; padding: 2px 6px 3px 6px;" value="Verify callback Signature" on Click="signcallback (document.callback)"/>
 <p></p>
</form>

### Spire Manual

#### Руководство пользователя

##### Подключение терминала по Bluetooth к IOS

Для создания пары mPOS терминала и IOS-устройства необходимо выполнить следующие действия:

1. Нажать желтую кнопку на терминале.
2. В появившемся меню выбрать пункт №1.

* В случае запроса терминалом кода супервайзера, необходимо ввести 8497 и подтвердить код, нажав зеленую кнопку на терминале.
* В случае отображения сообщения Идет спаривание, необходимо ожидание обнаружения iOS-устройством терминала по Bluetooth.

1. Проверить отображение iOS-устройства в разделе Bluetooth (устройство “Post Mate” или “SPххх”, где х - любая цифра).
2. В случае отображения устройства в доступных для подключения устройств Bluetooth, выбрать его и подключиться.
3. На дисплее IOS-устройства отобразится шестизначный код, который необходимо набрать на терминале и подтвердить зеленой кнопкой.
4. После этого будет создана пара mPOS-терминала с iOS-устройством.

##### Настройка терминала

Терминалы Spire настраиваются удаленно. В них заливаются следующие файлы:

* cakeys.cfg - CA ключи
* contactless.cfg - настройки бесконтакта
* currency_rub.cfg - настройки валют (Рубли)

В 99% случаев эти файлы загружаются беспроблемно, однако иногда:

1. Терминал сбрасывает настройки (производитель).
2. Проблемы с Bluetooth.

Также в терминалы загружаются два файла firmware: boot и masterfile. Они весят 300KB и 150KB соответственно. При заливке по Bluetooth через iPAD возникают ошибки при передаче файлов. В этом случае рекомендуется проверить версию firmware после заливки. Если не получилось залить, то нужно найти место, где нет других устройств с Bluetooth и повторить попытку, заново зайдя на страницу “Spire Terminals” и нажав на кнопку “Upload Firmware”.

##### Сброс настроек Bluetooth

<iframe width="871" height="490" src="https://www.youtube.com/embed/PX50c4XST6I" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Настройка Bluetooth

<iframe width="871" height="490" src="https://www.youtube.com/embed/j24JViHGPXE" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

#### FAQ

##### Бесконтактные платежи картами МИР на Spire SPm2 не проходят

Бесконтактные платежи картами МИР на Spire SPm2 НЕ работают.
 

##### Бесконтактные платежи на Spire SPm2 работают через раз

Подключить терминал по USB, чтобы он питался от сети перманентно.
 
В случае, если проблемы не устранились, обновить конфигурацию терминала.
 
В случае, если проблемы не устранились, отправить терминал производителю по гарантии.

### Statuses

#### Status List

| Status | Description |
|----------------|-----------------------------------------------------------------------------------------------------|
| approved | Transaction is approved, final status. |
| declined | Transaction is declined, final status. |
| error | Transaction is declined but something went wrong, please inform your account manager, final status. |
| filtered | Transaction is declined by fraud internal or external control systems, final status. |
| processing | Transaction is being processed, you should continue polling, non final status. |
| unknown | The status of transaction is unknown, please inform your account manager, non final status. |
| chain_declined | Transaction is declined in a cascading chain, non final status. |
\* after reconciliation transaction status could be changed even if transaction is in final status.
 
\*\* if transaction status haven’t been changed for one hour something went wrong, please stop polling and inform your account manager.
 
\*\*\* some APIs provide additional transaction statuses, if you’ve receive unlisted transaction status please inform your account manager.
 

#### 3D Secure Status List

| Value | Description |
|-------------------|---------------------------------------|
| AUTHENTICATED | Card MPI Status Y or A. |
| NOT_AUTHENTICATED | Card MPI Status N. |
| UNSUPPORTED | Card MPI Status U. |
| UNKNOWN | Verification have not been performed. |

#### Random Sum Check Status List

| Value | Description |
|-------------------|------------------------------------------------|
| AUTHENTICATED | The customer has entered correct random sum. |
| NOT_AUTHENTICATED | The customer has entered incorrect random sum. |
| UNSUPPORTED | The customer has not entered random sum. |
| UNKNOWN | Verification have not been performed. |

### Payneteasy test scenarios

<script src="../_static/js/generate_card_number.js"></script>

#### Transaction status test scenarios

Payneteasy system does not provide special card numbers to pass the test transactions. Instead of it you can use any valid credit card number and specify card verification codes from the list to get the desired result.

Please note that specified credit card numbers and CVV2 codes will work only on sandbox environment and can’t be used on production environment.

Next CVV2 codes can be used on sandbox environment to perform different answers from the system:

* 123 or 1234 to get an approved transaction;
* 321 for 3DS gates only, shows 3-D Secure validation form (hint is the correct 3-D Secure password to get approved transaction);
* 111 for 3DS gates only, immediately approves the transactions without 3-D Secure validation - emulates non-3DS flow for card that does not support 3-D Secure technology;
* 217 to get the transaction in unknown status (acquirer network problem emulation).
* 101 to get the transaction in decline status (expired card).
* 116 to get the transaction in decline status (not sufficient funds).
* 119 to get the transaction in decline status (Transaction not permitted to cardholder).
* 209 to get the transaction in decline status (Pick-up, stolen card).
* other CVV2 codes could be used to get the decline.

You can use following valid card numbers, if you haven\`t any or you want to check transactions for different payment systems.

 
On the sandbox.payneteasy.eu you can use the test cards and amounts listed below.
 

#### 3DS 1.0.2 test scenarios

##### 3DS 1.0.2 test cards

| Card Number | 3DS Method |
|---------------------|-----------------------|
| 4444 0000 2222 4444 | Present on server |
| 4444 0000 1111 8888 | Not present on server |

##### 3DS 1.0.2 test amounts

| Amount | Status | ECI | Description |
|----------|----------|-------|----------------------------------------------|
| 1.00 | Y | 00 | Request successfully processed |
| 1.01 | Y | 02 | Request successfully processed |
| 1.02 | Y | 05 | Request successfully processed |
| 1.03 | Y | 07 | Request successfully processed |
| 2.00 | A | 01 | User not enrolled |
| 2.01 | A | 06 | Authentication was not available |
| 3.00 | N | 05 | Transaction declined by authorization system |
| 3.01 | N | 07 | User Authentication Failed |
| 4.00 | U | 05 | Validation failed |
| 4.01 | U | 07 | Technical Error in 3D system |
| Other | | | You can select behavior on challenge form |

#### 3DS 2.x.0 test scenarios

##### 3DS 2.x.0 test cards

| Card Number | 3DS Method |
|---------------------|--------------------------------------------|
| 4444 5555 6666 1111 | Successful 3DS Method |
| 4444 2222 3333 9999 | Successful 3DS Method with 3 seconds delay |
| 4444 1111 2222 3333 | 3DS Method with 15 seconds delay |
| 4444 3333 1111 2222 | No 3DS Method ACS URL |

##### 3DS 2.x.0 test amounts

| Amount | Type | Status | Method data | ECI | Component | Description |
|----------|--------------|----------|---------------|-------|-------------|-------------------------------------------------------------------|
| 0.02 | Frictionless | | Conditional | | ARes | Invalid card |
| 0.03 | Challenge | | Conditional | | ARes | Success |
| 0.04 | Frictionless | | Conditional | | ARes | Access denied, invalid endpoint |
| 0.05 | Challenge | | Conditional | | RReq | User press Cancel on ACS |
| 0.06 | Challenge | | Conditional | | CRes | Wrong threeDSServer TransID and acs TransID |
| 0.07 | Challenge | | Conditional | | RReq | RReq = Success CRes = Fail |
| 0.08 | Challenge | | Conditional | | RReq | RReq = Fail CRes = Success |
| 1.01 | Frictionless | Y | Y | 05 | ARes | Successful frictionless authentication |
| 1.02 | Frictionless | Y | Y | 02 | ARes | Successful frictionless authentication |
| 1.03 | Frictionless | A | Y | 06 | ARes | Attempt |
| 1.04 | Frictionless | A | Y | 01 | ARes | Attempt |
| 1.05 | Frictionless | Y | N | 05 | ARes | Successful frictionless authentication |
| 1.06 | Frictionless | Y | N | 02 | ARes | Successful frictionless authentication |
| 1.07 | Frictionless | A | N | 06 | ARes | Attempt |
| 1.08 | Frictionless | A | N | 01 | ARes | Attempt |
| 2.03 | Frictionless | N | N | 01 | ARes | User not enrolled |
| 2.04 | Error | | | | | Card not participating |
| 3.01 | Challenge | C | Y | | RReq | Challenge |
| 3.02 | Challenge | C | N | | RReq | Challenge |
| 2.01 | Frictionless | U | N | | ARes | Technical Error |
| 2.02 | Frictionless | N | N | 06 | ARes | User not enrolled |
| 11.11 | Challenge | Y | Conditional | 02 | RReq | Success |
| Other | Challenge | | Conditional | | RReq | You can select behavior on challenge form |

> **Note:** Conditional – bases on test cards for 3DS Method

### Transfer Form

#### Introduction

Transfer is a type of complex transaction that allows to move funds between bank cards ([PAN](#transfer-form-definitions)), card tokens ([RPI](#transfer-form-definitions)) and Connecting Party bank account ([deposits](#transfer-form-definitions)).
 
Transfer-form integration is relevant for Connecting Party who are not able to accept sender card details (Connecting Party’s website must complete PCI DSS certification). Using Transfer Form integration Connecting Party is released of accepting payment details. In this case the accepting and processing of payment details is carried out on the Payneteasy side (if PAN is not sent). This type of integration also allows the Sender (for transfers between cards) or Receiver (for deposit to card) to submit their PAN on Payneteasy side.
 
 
All forms can be customized. Follow the [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) reference to see examples and macros of [Payment Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Prefilled Cardholder Data in Payment Page](https://doc.payneteasy.com/integration/reference/forms_customization.html.md), [Wait Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) and [Finish Page Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md).
 
 
See terms definitions in [Glossary](https://doc.payneteasy.com/integration/reference/glossary.html.md).
 
 
Transfer Form Use-Cases diagram:
 
```plantuml
hide members
hide circle

circle " " as c2
package From <<Frame>> {
class "Form" as f1a
class "Card number\n(Pan)" as pan1a
class "Reccuring Payment ID\n(RPI)" as rpi1a
class "Connecting Party Account\n(Deposit to card)" as dca

}
package To <<Frame>> {
class "Card number\n(PAN)" as pan2
class "Reccuring Payment ID\n(RPI)" as rpi2
class "Form" as f2

}

f1a --|> pan2
f1a --|> rpi2
f1a -- c2
pan1a -- c2
rpi1a -- c2
dca -- c2
dca -[hidden]> f2
c2 --|> f2
```

Possible transfer form Use-Cases:

| Form to PAN | Transfer from Form to PAN occurs when transferring funds from payment details indicated in form to bank card for which its number is indicated. |
|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Form to RPI | Transfer from Form to RPI occurs when funds are transferred from payment details indicated in form to bank card for which its recurring payment id is indicated. |
| PAN to Form | Transfer from PAN to Form occurs when funds are transferred from one bank card for which its number is indicated to payment details indicated in form. |
| RPI to Form | Transfer from RPI to Form occurs when funds are transferred from one bank card for which its recurring payment id is indicated to payment details indicated in form. |
| Form to Form | Transfer from Form to Form occurs when funds are transferred from payment details indicated in form to another payment details indicated in form. |
| deposit to Form | Transfer from deposit to Form occurs when funds are transferred from Connecting Party account to payment details indicated in form. |

#### Transfer Flow

```plantuml
skinparam roundcorner 20
skinparam sequenceArrowThickness 2
skinparam ParticipantPadding 30
autonumber
actor Sender as Payer
participant "Connecting Party" as A
participant "Payment Gateway" as B
Payer -> A: Payment Initiation
activate A
== Transfer Request ==
A -> B: api/v4/transfer-form
activate B
B --> A: Redirect-url, orderId
deactivate B
A -> Payer: Provide redirect-url to sender’s browser
deactivate A
activate Payer
Payer -> B: GET redirect-url
deactivate Payer
activate B
B --> Payer: Transfer Form
deactivate B
activate Payer
Payer -> B: Submit form
deactivate Payer
activate B
B -> B: Process payment
== Final redirect of Payer ==
B -> Payer: Connecting Party website redirect_url
activate Payer
Payer -> A: POST redirect_url status, orderid
deactivate Payer
activate A
group Get Final Status
== Receive Callback ==
A <- B: Сallback with final status
B <-- A: HTTP 200
deactivate B
== Order Status Request ==
A -> B: Get status by Order ID
activate B
B --> A: Final Status
deactivate B
end
A --> Payer: Show Result
deactivate Payer
deactivate A
```

(1) Transfers between cards are initiated by Sender. Transfer from Connecting Party ([deposits](#transfer-form-definitions)) are initiated by Receiver, with the same transaction flow.
 
(2) To implement transfer-form request see [/api/v4/transfer-form/](https://doc.payneteasy.com/integration/API_commands/api_v4_transfer-form.html.md).
 
(9) To implement final redirect see [Final Redirect](https://doc.payneteasy.com/integration/API_commands/final_redirect.html.md).
 
(11) To implement callback with final status handling see [Connecting Party Callbacks](https://doc.payneteasy.com/integration/API_commands/merchant_callback_parameters.html.md).
 
(13) To implement order status see [/api/v2/status/](https://doc.payneteasy.com/integration/API_commands/api_v2_status.html.md). Status should be requested multiple times with 3-5 seconds interval until final status will be received in response.

### /api/3ds/v1/upload-cres-result

After receiving c Res value to notificationURL, upload the results using HTTP POST request to [URLs](#api-3ds-v1-upload-cres-result-url) and the [parameters](#api-3ds-v1-upload-cres-result-parameters) specified below.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-cres-result/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-cres-result/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-cres-result/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-cres-result/ENDPOINTGROUPID |

#### Request Parameters

| Parameter Name | Max Length | Description |
|------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| c Res | 4096 | The CRes message is the ACS response to the CReq message. It indicates the result of the Cardholder authentication. |
| orderid | 128 | Order id assigned to the order by Payneteasy. |
| login | 20 | Merchant login name. |
| client-order-id | 128 | Merchant order identifier. |
| control | 40 | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. login 2. client_orderid 3. orderid 4. merchant_control (Control key assigned to Merchant account in the Payneteasy gateway system) |

#### Response Parameters

| Parameter Name | Description |
|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Merchant order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |

#### Request Example

```http
POST /paynet/api/3ds/v1/upload-cres-result/39529 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 495
Content-Type: application/x-www-form-urlencoded
Connection: close

cres=ewogICJtZXNzYWdlVHlwZSIgICAgOiAiQ1JlcyIsCiAgIm1lc3NhZ2VWZXJzaW9uIiA6ICIyLjEuMCIsCgogICJ0aHJlZURTU2VydmVyVHJhbnNJRCIgOiAiZDAwYTdhZmUtMmE0ZC00NmI0LThmN2YtZjRlZmFkZjE0MmIzIiwKICAiYWNzVHJhbnNJRCIgICAgICAgICAgIDogImFjYWMwMzAxLTVlMWItNDk3Yy04NzA0LTZkNTU5NTc1YTRmZSIsCgogICJjaGFsbGVuZ2VDb21wbGV0aW9uSW5kIiA6ICJZIiwKICAidHJhbnNTdGF0dXMiICAgICAgICAgICAgOiAiWSIKfQ==
&orderid=6684126
&control=d0539beedb9a7266547530c8d2027f2b14503a61
&login=test1
&client-order-id=1e21f041-871d-4642-a6d9-968457df47a0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=async-response
&serial-number=00000000-0000-0000-0000-000002d6202d
&merchant-order-id=1e21f041-871d-4642-a6d9-968457df47a0
&paynet-order-id=6684126
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=validation-error
&serial-number=00000000-0000-0000-0000-000002b36f64
&merchant-order-id=inv4097763
&error-message=End+point+with+id+22903+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/3ds/v1/upload-cres-result/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/3ds/v1/upload-method-url-result

After completing the 3DS Method and gathering customer browser fingerprint, upload the results using HTTP POST request to [URLs](#api-3ds-v1-upload-method-url-result-url) and the [parameters](#api-3ds-v1-upload-method-url-result-parameters) specified below.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-method-url-result/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-method-url-result/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-method-url-result/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-method-url-result/ENDPOINTGROUPID |

#### Request Parameters

| Parameter Name | Length | Description |
|--------------------------|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| orderid | max 128 | Order id assigned to the order by Payneteasy. |
| login | max 20 | Merchant login name. |
| client-order-id | max 128 | Merchant order identifier. |
| control | max 40 | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. login 2. client_orderid 3. orderid 4. merchant_control (Control key assigned to Merchant account in the Payneteasy gateway system) |
| threeDSServer TransID | max 36 | 3DS Server Transaction ID. Universally unique transaction identifier assigned by the 3DS Server to identify a single transaction. |
| browser Accept Header | max 2048 | Browser Accept Headers. Exact content of the HTTP accept headers as sent to the 3DS Requestor from the Cardholder’s browser. |
| browserIP | max 45 | Browser IP Address.\* |
| browser Java Enabled | min 4, max 5 | true/false Browser Java Enabled. Boolean that represents the ability of the cardholder browser to execute java. Value is returned from the navigator.java Enabled property. |
| browser Javascript Enabled | min 4, max 5 | true/false Browser Java Script Enabled. Boolean that represents the ability of the cardholder browser to execute javascript. |
| browser Language | max 8 | Value representing the browser language as defined in IETF BCP47. Returned from navigator.language property. |
| browser Color Depth | max 2 | Browser Screen Color Depth. Value representing the bit depth of the colour palette for displaying images, in bits per pixel. Obtained from Cardholder browser using the screen.color Depth property |
| browser Screen Height | max 6 | Browser Screen Height. Total height of the cardholder’s screen in pixels. Value is returned from the screen.height property. |
| browser Screen Width | max 6 | Browser Screen Width. Total width of the cardholder’s screen in pixels. Value is returned from the screen.width property. |
| browserTZ | max 5 | Browser Time Zone. Time difference between UTC time and the cardholder browser local time, in minutes. Value is returned from the get Timezone Offset() method. |
| browser User Agent | max 2048 | Browser User-Agent. Exact content of the HTTP user-agent header. Note: If the total length of the User-Agent sent by the browser exceeds 2048 characters, the 3DS Server truncates the excess portion. |
| threeDSComp Ind | max 1 | 3DS Method Completion. Indicates whether the 3DS Method was successfully completed. Values accepted: `Y` = Successfully completed `N` = Did not successfully complete. The 3DS Method was not completed within 10 seconds. `U` = Unavailable — tds-method-url-frame-3ds-method-url was not present in Status response. |
| notificationURL | max 256 | Fully qualified URL of merchant system that will receive the CRes message or Error Message. The CRes message is posted by the ACS through the Cardholder browser at the end of the challenge. |

> **Note:** \* IP address of the browser as returned by the HTTP headers to the 3DS Requestor IPv4 address is represented in the dotted decimal format of 4 sets of decimal numbers separated by dots.

The decimal number in each and every set is in the range 0 to 255.
 
Example IPv4 address: 1.12.123.255
 
 
IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets. The groups are separated by colons (:).
 
Example IPv6 address: 2011:0db8:85a3:0101:0101:8a2e:0370:7334
 

#### Response Parameters

| Parameter Name | Description |
|-------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details. |
| paynet-order-id | Order id assigned to the order by Payneteasy. |
| merchant-order-id | Merchant order id. |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant. |
| error-message | If status is error this parameter contains the reason for decline or error details. |
| error-code | The error code is case of error status. |
| end-point-id | Endpoint id used for the transaction. |

#### Request Example

```http
POST /paynet/api/3ds/v1/upload-method-url-result/39529 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 721
Content-Type: application/x-www-form-urlencoded
Connection: close

notificationURL=https://merchant.com/shop/notification/1e21f041-871d-4642-a6d9-968457df47a0
&browserLanguage=en-us
&orderid=6684126
&browserColorDepth=24
&browserJavaEnabled=false
&control=24dc828de77bae41b9c4bf4dcbdb5c80158eb2db
&login=test_merchant
&browserIP=10.25.8.19
&browserUserAgent=Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/14.0 Safari/605.1.15
&browserAcceptHeader=text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
&browserTZ=-180
&browserScreenHeight=900
&browserJavascriptEnabled=true
&threeDSCompInd=Y
&browserScreenWidth=1440
&client-order-id=1e21f041-871d-4642-a6d9-968457df47a0
&threeDSServerTransID=d00a7afe-2a4d-46b4-8f7f-f4efadf142b3
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=async-response
&serial-number=00000000-0000-0000-0000-000002d62029
&merchant-order-id=1e21f041-871d-4642-a6d9-968457df47a0
&paynet-order-id=6684126
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=validation-error
&serial-number=00000000-0000-0000-0000-000002b36f64
&merchant-order-id=inv4097763
&error-message=End+point+with+id+22903+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/3ds/v1/upload-method-url-result/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### /api/3ds/v1/upload-pares-result

#### Upload Pa Res Result

After receiving pa Res value to Term Url, upload the results using HTTP POST request to [URLs](#api-3ds-v1-upload-pares-result-url) and the [parameters](#api-3ds-v1-upload-pares-result-parameters) specified below.

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|-------------------------------------------------------------------------------------|----------------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-pares-result/ENDPOINTID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-pares-result/ENDPOINTID |
| https://sandbox.payneteasy.eu/paynet/api/3ds/v1/upload-pares-result/ENDPOINTGROUPID | https://gate.payneteasy.eu/paynet/api/3ds/v1/upload-pares-result/ENDPOINTGROUPID |

#### Request Parameters

| Parameter Name | Max Length | Description |
|------------------|--------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| pa Res | 10240 | Payer Authentication Response message is returned by the ACS with the result of cardholder payment authentication. |
| orderid | 128 | Order id assigned to the order by Payneteasy. |
| login | 20 | Merchant login name. |
| client-order-id | 128 | Merchant order identifier. |
| control | 40 | Checksum generated by [SHA-1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/sha.html.md). Control string is represented as concatenation of the following parameters: 1. login 2. client_orderid 3. orderid 4. merchant_control (Control key assigned to Merchant account in the Payneteasy gateway system) |

#### Response Parameters

| Parameter Name | Description |
|-------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| type | The type of response. May be async-response, validation-error, error. If type equals validation-error or error, error-message and error-code parameters contain error details |
| paynet-order-id | Order id assigned to the order by Payneteasy |
| merchant-order-id | Merchant order id |
| serial-number | Unique number assigned by Payneteasy server to particular request from the Merchant |
| error-message | If status is error this parameter contains the reason for decline or error details |
| error-code | The error code is case of error status |

#### Request Example

```http
POST /paynet/api/3ds/v1/upload-pares-result/39529 HTTP/1.1
User-Agent: curl/7.83.0
Accept: */*
Content-Length: 2631
Content-Type: application/x-www-form-urlencoded
Connection: close

orderid=6684127
&md=BB4A517A42736975764E3453302B303144794D754B7A4F697A7953765930784259503870546A79416F6542646F4E4A69534F3243317431726A6352702B68565271
&paRes=eJydlluTokgThu/nVxhOxN4YPZwV5rPdKI6CgHIQxTsaEDnIWUB//aL09Ngdc7HfcgFFkvnwZmVWRc3/7s7JqPHLKszS1zHyAx6P/NTNvDANXsdbk38hx6OqdlLPSbLUfx2n2fjvxdw8lb7PGr57Kf3Ft9FoNFf8qnICfxR6r2P4/Xr5dUM+Rv01JY6edxw/wu6RG6D71f8fdw99173oZf9A59Cv1ycPxS/dk5PWT7a72XELWlQXOIJMCXIOvb9+9jn7pcguEBTDiemMpOA5NFie6NAf8PPN5W6r/C+4LvQWamTjKstdVZhRuPwk8vvOkKPDbt2A1zl09/gc4zm1v0BhFEFgdDaC0Z8I/BPvE33YP7v2lSj7wl0XUxybQx9vn538Lu+L2MvtGR/jzy75XT04Z5f+C3Kf9jn0bHpO/g+JznMnXcxQjIBRlJgRBIGi6Gw6JQmSmvU2pJ/ru8dTgLn/IqAOz59zxqmfBDGHHvbPrn1f1pdqYc+h99GXbN1wAfeR9+ez7t+/7HO4N9/QwUYYpD2l9Ef9kkir1/GprvOfENS27Y8W+5GVAYT28wHBFNQ7eFUYfB8vHlG+J6bHbDFnnDRLQ9dJwptT942o+PUp80YgCbIyrE/nPyFN/U5FIJ1jXnrsi4vg6cvdAmMIMYYWv2X9G9pXgWXlvFQnB7mDdP/o35vCH2118XX8/d+ttjkbBn5V/5ef//rxQLCc5OIvVLFd0tZGl5PaWkMNtmqIDYDqdQnh/Qp49pxDH4L78fM0f8zI4ChXgtEZhyIt0K6WdJy5vhUC2dnwKScKue1cfDNt8ZlKzFaheInrfQNtd44xWZaSiTh2q+mWZ6gTqN0I7F/fEex/31QZhlr2sgOIutoh2tlvOKiBsCyuaDTx1ifdz72tLNgXrcJ8xvBpouWza+G0+DJwILpyCkrN+Qll5idnIIoYvK3WmLDCzukJmxWQkjmkncm0S7jN7AbsSA9xDGwm1ZbxogMeHwywYgpR32FwNUHla0rGF5ZChN2qGIjsmfYPqJQIlGKqWcLoYMXVuupPJrk+ESZhh+5YCIrVYi1NCDoPpWXrOuky80TBzLRbmsxcoKAcRs6C/UAs5KVhozuIn/oB7iH224yPfBviFW7Ke911RebqRQleX4diPBVgvvKvQ2X2BEyxTu0MI8Yv6/DYr4d+s1JEkd2yDAOigGE05mY62yk6YW+HG1DpIC5OcShQLUwDreIBSxeKVrWMZrOWpglcK9k7lpMVEAsA2XKDXAa0zI4POs4EGzpQLRq4CsPriYvpkbPXCUXXWi54EFYsqLeHvQprKFW7An/xTU5XAPmgMW0rDkRLsG4eb12cvdZxEdAGqqIw1oNK25jSKibw+Ra+9k9CYeNOMblbXwDnYYt+2wbi/YsiZB1zA9JAs02QnOyn7EQWPLL70EP3eh5KBDX3lnHHs8C4xw5EGmQKgzz0sG8o0to7os+Ua9n2QZNZcHpkau2I3GM5Q6HBgwraVnpQOT5yb6Dr60G/t2b0tQIcD8CaARoJ7l5MsOrHHECQws5DYVJaBy5MOjzbe3GL+JjH0NaK4Fy53xoGorGKpfqYi2wDgSu8v8UJFC831Zt8pRhCQmK3K0wYz3QxMLeacHEsam0Gld1SwnIWQKR6EN84ZT2N6F2yG4gJqabAXreFaDh2pcrbyJZo/GAdaCWIeaXgSpFgGdN0Qbd+Q69YZbilJEWWVfjTc3EKOXrvULeio4woHojt4TpDqBPxpsrTmshXpLnd8Yl7zWaYpdRtgFsk1pDAMugusQBIrJp3G9DYcllPrh2JGLGVLtE9pl4kZiCetLXfyDY8WW4beD/btHbphr2inYQRgqhY0Cw/LI03wfCCIxxCFdvcWKEHZJ2A7+ibdlsXtIGtnOzW5QMRa/vm0ACtAFhgjEIwxDeM1TiaabcA4GJfKZpIG87BcaqY6da6ZByDu1x1WyHI2yTh4BsxwQz5LYowfiBGhcupZ4/zk9UVeGQLKzB3nZS7xGFX2rrOupaLkq00QSZr0loiql4yjeBsjpJtxlvnyGIrfyn1fYutdu8dnjNxkqCqvAq3pmDlR+QApwpWoUZsg6iaIC61OU6yvTpLwgt0FVW2wVXytJajOF+SmL3ZSxRqvWktdbm+d3hE+RtJ2/gGdswlzoeJGK0tqk21NaVFbkfthLUCkfLyIBy8oyi1K2epL/GqPbrttVQamLLcDWSk28Su39d1UyRkgxZ2sybgTC+9DK4PRiNLOyKZGmZ18qMqv+jQ8lozEKVHDELWuJpSvHWeuSzC9eekmaqJq3oOfd3VBsuw40Efu+Dv/XFxPyE+zsWLb/254/nQ/A8pzm2f
&control=987e7aa6630a862805c65eee02392d7a769cadbe
&login=test_merchant
&client-order-id=e690bf9f-0c90-4073-a30a-604d13ae9fb9
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=async-response
&serial-number=00000000-0000-0000-0000-000002d62036
&merchant-order-id=e690bf9f-0c90-4073-a30a-604d13ae9fb9
&paynet-order-id=6684127
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Wed, 17 Nov 2021 11:03:17 GMT
Content-Type: text/html;charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Keep-Alive: timeout=60
Vary: Accept-Encoding
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Content-Language: ru-RU
P3P: CP="NOI ADM DEV COM NAV OUR STP"
Content-Encoding: gzip

type=validation-error
&serial-number=00000000-0000-0000-0000-000002b36f64
&merchant-order-id=inv4097763
&error-message=End+point+with+id+22903+not+found
&error-code=3
```

#### Open API Collection

Open this method in the OpenAPI Reference

<a class="openapi-reference-button" href="/openapi-doc/#POST/api/3ds/v1/upload-pares-result/{endpoint Id}" target="_blank" rel="noopener">View in OpenAPI <svg xmlns="http://www.w3.org/2000/svg" view Box="0 0 24 24" fill="none" stroke="current Color" stroke-width="2" stroke-linecap="round" stroke-linejoin="round"><path d="M18 13v6a2 2 0 0 1-2 2H5a2 2 0 0 1-2-2V8a2 2 0 0 1 2-2h6"/><polyline points="15 3 21 3 21 9"/><line x1="10" y1="14" x2="21" y2="3"/></svg></a>

### Verifone Manual

#### Руководство администратора

##### Перевод терминала Verifone в режим работы через USB-порт

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Связь с банком / Через кассу
* Параметры / Редактирование / Smart Sale / Порт терминала / USB
* Параметры / Редактирование / Smart Sale / SSL без ККМ / Да

<iframe width="871" height="490" src="https://www.youtube.com/embed/S_QGNcmR2tU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Переключение терминала в режим работы с USB порта на Ethernet

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Связь с банком / Через терминал
* Параметры / Редактирование / Smart Sale / Порт терминала / Ethernet

<iframe width="871" height="490" src="https://www.youtube.com/embed/x Dm Av Zl YfEU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Настройка терминала на работу без кассы

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Редактирование / Smart Sale / Режим ККМ / Касса или Терминал (по умолчанию - Касса)

1. После установки параметра терминал перезагрузится и в меню появится иконка для инициации платежа.

> **Note:** В этом режиме терминала Verifone печать слипов (чеков платежной системы) невозможна, т.к. принтер отсутствует.

##### Создание нового кассира

1. Войти в меню администратора, см. ниже.
2. Установить следующие параметры:

* Параметры / Управление доступом / Управление правами / Новый оператор - создать нового оператора в группу “Кассиры” и установить пароль (на этапе “Введите карту доступа” нажать Enter).
* Параметры / Управление доступом / Авто логин - выбрать нужного оператора (в случае необходимости).

##### Вход меню Администратора

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт меню “Блокировка терм.” и нажать ENTER.
4. Выбрать пункт “Администратор”, ввести пароль Администратора, затем нажать ENTER.

##### Загрузка модуля CTLS на терминал Verifone

1. Скачать USB Driver, POS Loader и OS_Remote Update Pkg.zip [по ссылке](https://inpas.ru/content/svobodno-rasprostranyaemoe-po).
2. Установить USB Driver и POS Loader.
3. Запустить POS Loader, нажать Терминал, выбрать Verifone.
4. Подключить терминал к USB и к Ethernet-сети.
5. В POS Loader нажать “Файл” > “COM порт”, затем выбрать порт.
6. На терминале зажать клавиши 7 и ENTER одновременно.
7. Ввести пароль для входа в инженерное меню.
8. Выбрать Download (3) – Enter – 166831 – Single-app (1) – Partial dnld (2) – USB Dev (7).

> **Warning:** Пункт Full download не должен быть выбран.

1. Выбрать Загрузить CTLS, выбрать Нет. Дождаться завершения загрузки на терминале.

> **Warning:** Обязательно выбирать в диалоге НЕТ.

1. Провести тестовую оплату с помощью бесконтактной карты (не Apple/Google Pay).

##### Изменить идентификатор терминала

1. Выбрать пункт меню Параметры.
2. Выбрать Редактирование.
3. Выбрать Настройка агента.
4. Для входа в меню Параметры приложения, нажать 1.
5. Стереть неправильный номер терминала и ввести новый. Правильный номер терминала вводится исходя из его серийного номера. Серийный номер находится на нижней части терминала. Идентификатор терминала должен состоять из восьми цифр.

> **Note:** Для Verifone не вводить первую цифру и знак тире. Например, если серийный номер терминала 123-456-789, то нужно ввести 23456789.

##### Настройка Wi-Fi

<iframe width="871" height="490" src="https://www.youtube.com/embed/fYEBXHpnT8E" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

#### Руководство пользователя

##### Подключение терминала к сети Ethernet

1. Подключить кабель к разъему с надписью ETH.
2. Дождаться смены цвета иконки ETH с красной на зеленую в статусной строке экрана.
3. На роутере найти IP-адрес терминала по его MAC-адресу и закрепить его на DHCP-сервере роутера за терминалом. MAC-адрес терминала написан на желтой этикетке на нижней панели терминала.
4. При включении терминал должен успешно установить соединение с сервером.

##### Нахождение IP-адреса терминала в сети

Поиск IP-адреса Pax/Verifone в сети производится самостоятельно. Указание диапазона не обязательно.

Ограничения:

* Маска сети не должна выдавать больше 500 IP адресов.
* При нахождении больше одного терминала отобразится ошибка.

> **Note:** В случае присутствия больше одного терминала в сети, может быть указан его идентификатор (например, terminal_id=12345678) после чего терминал может быть проверен.

Правила для заполнения поля address:

* В случае присутствия в сети одного терминала и количество IP-адресов меньше 500, нет необходимости вводить данные.
* В случае присутствия в сети больше одного терминала и количество IP-адресов меньше 500, необходимо ввести идентификатор терминала (например, terminal_id=12345678).
* В случае присутствия в сети одного терминала и количество IP-адресов больше 500 IP-адресов, необходимо указать диапазон поиска IP-range (например, range=192.168.0.1-192.168.0.254).
* В случае присутствия в сети больше одного терминала и количество IP-адресов больше 500, необходимо ввести идентификатор терминала или диапазон поиска IP-range на выбор.

> **Note:** Установка программы для поиска терминала на [iOS](https://mpos.pne.io/scanner/ios/install.html) и [Android](https://mpos.pne.io/verifone/scanner/scanner.apk).

##### Автоматический поиск терминала (только для IOS)

* В настройках терминала прописать диапазон, в котором будет находится терминал (например, range=10.45.69.1-10.45.69.254:27015).

##### Обновление конфигурации

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 3 и ENTER одновременно.
2. Ввести пароль 1234 и нажать ENTER.
3. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

* В случае подключения терминала по USB, после отображения сообщения Загрузка параметров будет отложена нажать ENTER. Затем необходимо провести оплату, во время которой будет произведено обновление конфигурации.
* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

<iframe width="871" height="490" src="https://www.youtube.com/embed/MSlpEIaO0B0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Нажимать на ENTER (курсор на пункте ЗАГРУЗКА ПАРАМ.).
5. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

* В случае подключения терминала по USB, после отображения сообщения Загрузка параметров будет отложена нажать ENTER.
* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

##### Отправка логов на сервер

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 2 и ENTER одновременно.
2. Ожидать отправки логов на сервер.

<iframe width="871" height="490" src="https://www.youtube.com/embed/RHGZGYRx64k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Выбрать пункт меню Логирование.
5. Выбрать пункт Выгрузка лога.
6. В случае подключения терминала по USB, после отображения сообщения Выгрузка логов будет отложена нажать ENTER. Затем необходимо произвести оплату, во время которой будет произведено обновление конфигурации.

* В случае подключения терминала по Ethernet, подключение к сети и загрузка программ пройдет автоматически.

#### Руководство пользователя Verifone Vx680

Руководство по установке может быть найдено по [ссылке](https://www.pos-shop.ru/upload/iblock/fac/verifone-vx680.pdf).

##### Включение

Нажать ENTER (зеленая кнопка). Если не включается, то зарядить.

<iframe width="871" height="490" src="https://www.youtube.com/embed/2zadW9ylou0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Выключение

Нажать на CANCEL (красная кнопка) и удерживать в течение 10 сенунд.

<iframe width="871" height="490" src="https://www.youtube.com/embed/BEGPgnAGW8Q" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

##### Вход в меню

Нажать клавиши 5 и ENTER (сначала 5, потом ENTER).

##### Оплата

> `sale-vx680 POS_m Pos`

##### Отмена платежа

> `cancel-vx680 POS_m Pos`

##### Сверка итогов

> `reconciliation-vx680 POS_m Pos`

##### Обновление конфигурации

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 3 и ENTER одновременно.
2. Ввести пароль 1234 и нажать ENTER.

1. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

<iframe width="871" height="490" src="https://www.youtube.com/embed/MSlpEIaO0B0" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Нажать на ENTER (курсор на пункте ЗАГРУЗКА ПАРАМ.).
5. После отображения сообщения Журнал содержит операции, возможны финансовые потери. Продолжить? нажать ENTER.

##### Отправка логов на сервер

###### Способ №1

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем зажать клавиши 2 и ENTER одновременно.
2. Ожидать отправки логов на сервер.

<iframe width="871" height="490" src="https://www.youtube.com/embed/RHGZGYRx64k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>

###### Способ №2

1. Дождаться логотипа или надписи Ожидание команды от ККМ, затем нажать ENTER.
2. Ввести пароль 1234 и нажать ENTER.
3. Выбрать пункт Параметры, нажав кнопку 6, затем нажать ENTER.
4. Выбрать пункт меню Логирование.
5. Выбрать пункт Выгрузка лога.

#### FAQ

##### При включении терминала постоянно просит ввести сумму.

На терминале кто-то активировал режим работы с терминалов для ввода суммы. Зайти в меню настройки Smart Sale и включите режим работы терминала только с кассой.
 

> **Note:** Нажать 5 + ENTER (сначала 5, потом ENTER).

##### Не получается провести сверку итогов: 3 + Enter завершается с ошибкой, 4+Enter и через программу mpos-mtips-advt не получается выполнить

Необходимо проверить на терминале в настройках, правильно ли введен 8-ми значный номер терминала (первая 9-ка и тире отбрасываются: s/n на корпусе - 902-692-123, то номер в настройках - 02692123).
 
Смена номера терминала описана в разделе “Руководство администратора” -> “Изменить идентификатор терминала”.
 

##### Поиск IP-адреса Verifone в сети

Установить [программу поиска IP-адреса](https://dengisend.ru/demo-ios/Socket Scaner/install.html).
 

##### Восстановление терминала после ошибки -3158

Ошибка связана с повреждением базы данных, которая находится в файле UNIPOS.DBI. Для ее исправления необходимо обнулить файл UNIPOS.DBI.
 
Шаги для восстановления:
 
<iframe width="871" height="490" src="https://www.youtube.com/embed/zf87avgga-A" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
1. Включите терминал. Дождитесь, пока появится сообщение об ошибке.
2. Подключите mini USB кабель к компьютеру и терминалу.
3. Подключаем mini USB к терминалу в блок расширения, где подключен кабель ethernet к терминалу. Компьютер должен определить терминал как COM-порт. Если этого не произошло, то установите [драйвер](https://mpos.pne.io/verifone/Verifone Unified Driver Installer-5.0.4.0-B10.zip).
4. Затем необходимо выяснить, к какому COM-порту подключен терминал. Для этого на иконке Компьютер нажав ПКМ и выбрать пункт Управление. Затем перейдите в раздел Диспетчер устройств. Раскройте в дереве устройств узел Порты (COM и LPT). Выяснить порт, к которому подключен Verifone.

Перевод терминала в инженерный режим.
 

На терминале:

1. Нажать на терминале клавиши 7 и ENTER одновременно.
2. Ввести пароль 166831. Дождаться перехода терминала в специальный режим VERIX TERMINAL MGR.
3. Выбрать пункт Download, нажав клавишу 3, затем нажать ENTER. При этом будет выбрана Group \_ID: 1.
4. Ввести еще раз пароль 166831, затем нажать ENTER.
5. Выбрать пункт Single-app, нажав клавишу 1.
6. Выбрать пункт Partial dnld, нажав клавишу 2.
7. Выбрать пункт USB Dev, нажав клавишу 7.
8. Терминал отобразит надпись WAITING FOR DOWNLOAD.

Запуск программы на компьютере
 

На компьютере:

1. Скачать файл [ddl.exe](https://mpos.pne.io/verifone/ddl.exe).
2. Открыть командную стоку с помощью cmd.exe.
3. Запустить ddl.exe в окне.

```text
c:\Users\Download\ddl.exe -p <port_number> -r UNIPOS.DBI
```

Где <port_number> - это номер COM-порта Verifone.

c:Users Download- куда была скачана программа ddl.exe

1. Перезапустить терминал.
2. Нажать ENTER. (Пункт меню 1> Restart).

После этого терминал перегрузится и начнет работать в штатном режиме.
 

##### Первичная установка терминала

Если при включении Verifone показывает следующую надпись:

```text
DOWNLOAD NEEDED GO FILE NOT FOUND
```

 *Видео процесса установки*

С компьютера:
 
<iframe width="871" height="490" src="https://www.youtube.com/embed/NVqKFLc4hjU" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
С терминала:
 
<iframe width="871" height="490" src="https://www.youtube.com/embed/9axPZIBVN7k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
Шаг 1: USB кабель
 
1. Подключить mini USB кабель к компьютеру.
2. Подключить mini USB к терминалу в блок расширения, где подключен кабель ethernet к терминалу.
3. Компьютер должен определить терминал как COM-порт. Если этого не произошло, то установить [драйвер](http://mpos.pne.io/verifone/Verifone Unified Driver Installer-5.0.4.0-B10.zip).
4. Затем необходимо выяснить, к какому COM-порту подключен терминал. Для этого на иконке Компьютер нажав ПКМ и выбрать пункт Управление. Затем перейдите в раздел Диспетчер устройств. Раскройте в дереве устройств узел Порты (COM и LPT). Выяснить порт, к которому подключен Verifone.

Шаг 2: Запуск программы на компьютере
 

Установка программы UNIPOS на терминал с помощью компьютера.

1. Создать каталог c:verifone.
2. Скачать файлы [ddl.exe](http://mpos.pne.io/verifone/ddl.exe), [OW_BASE.zip](https://mpos.pne.io/verifone/OW_BASE_2.0.13.014_RU.zip) и [Parameters.zip](https://mpos.pne.io/verifone/02692552_Parameters.zip), сохранить их в каталог c:verifone.
3. Открыть командную стоку с помощью cmd.exe и перейти в каталог c:verifone

```text
cd c:\verifone
```

1. Запустить следующую программу с параметрами:

```text
ddl.exe -p 3 -b115200 *UNZIP=OW_BASE_2.0.13.014_RU.zip -iOW_BASE_2.0.13.014_RU.zip CRYPTOTYPE=V
```

1. После окончания загрузки терминал перегрузится сам.

Шаг 3: отмена загрузки ключей
 
1. После первой загрузки терминал покажет меню загрузки ключей.
2. Нажать CANCEL.
3. Терминал перезагрузится еще раз.

Шаг 4: Загрузка параметров
 
1. После загрузки отобразится сообщение Параметры не загружены. Перевести терминал в инженерный режим. Нажать на терминале клавиши 7 и ENTER одновременно.
2. Ввести пароль 166831. Дождаться перехода терминала в специальный режим VERIX TERMINAL MGR.
3. Выбрать пункт Download, нажав клавишу 3, затем нажать ENTER. При этом будет выбрана Group \_ID: 1.
4. Ввести еще раз пароль 166831, затем нажать ENTER.
5. Выбрать пункт Single-app, нажав клавишу 1.
6. Выбрать пункт Partial dnld, нажав клавишу 2.
7. Выбрать пункт USB Dev, нажав клавишу 7.
8. Терминал отобразит надпись WAITING FOR DOWNLOAD.

Шаг 5: Загрузка параметров
 
* В командной строке в каталоге c:verifone выполнить следующую команду:

```text
ddl.exe -p3 -b115200 *UNZIP2=02692552_Parameters.zip -i02692552_Parameters.zip
```

Шаг 6: Создание администратора
 
1. После перезагрузки терминал может отобразить сообщение Создание администратора при первой загрузке.

<iframe width="871" height="490" src="https://www.youtube.com/embed/9axPZIBVN7k" frameborder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowfullscreen></iframe>
1. Для этого ввести имя пользователя ROOT.
2. На предложение ввести смарт-карту нвжвть CANCEL.
3. Пароль 1478.

Шаг 7: Настройка номера терминала
 
1. После загрузки нажать клавиши 3 и ENTER на терминале.
2. Ввести номер терминала 02692552.

### /view-invoice-xml

#### Introduction

To start Swift transaction use [/api/v2/auth-cash/](https://doc.payneteasy.com/integration/api_v2_auth-cash.html.md) and get receipt-id in [order status response](https://doc.payneteasy.com/integration/api_v2_status.html.md). Swift invoice in XML is initiated through HTTPS GET request by using [URLs](#view-invoice-xml-url) specified below. Use [HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|----------------------------------------------------------------------------|-------------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/view-invoice-xml/ENDPOINTID/RECEIPTID | https://gate.payneteasy.eu/paynet/view-invoice-xml/ENDPOINTID/RECEIPTID |

#### Request Example

```http
POST /paynet/view-invoice-xml/6657/6d0442b3-f4f9-3264-8cfd-f811195b693a HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1687422393",oauth_nonce="I4FlRMNDFfe",oauth_signature_method="HMAC-SHA1",oauth_signature="sW7XXVhkxXAwE61CLnwCpjxJpD0%3D"
Content-Length: 140
Content-Type: application/x-www-form-urlencoded
Connection: close

oauth_consumer_key=test_merch
&oauth_nonce=I4FlRMNDFfe
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687422393
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Thu, 22 Jun 2023 08:26:51 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 833
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<root>
<pdf_template_name>swift_local.xslt</pdf_template_name>
<additional_params/>
<date>22.06.2023</date>
<bank_name>TestBank</bank_name>
<bank_address>Lima, Peru</bank_address>
<company_name>Company</company_name>
<company_address>P. Sherman 42 Wallaby way</company_address>
<iban>1122334455</iban>
<swift>123IAMS123</swift>
<customer>
<firstname>John</firstname>
<lastname>Smith</lastname>
<address>98102, United States, WA, Seattle, 100 Main st</address>
<phone>12063582043</phone>
<cell_phone>19023384543</cell_phone>
</customer>
<rate>1</rate>
<quantity>1</quantity>
<currency>EUR</currency>
<amount>10</amount>
<order_desc>Test Order Description</order_desc>
<invoice_no>6657-587</invoice_no>
<order_invoice_no>902B4FF5</order_invoice_no>
<reference_id>1</reference_id>
</root>
```

#### Fail Response Example

```http
HTTP/1.1 404
Server: server
Date: Thu, 22 Jun 2023 08:30:18 GMT
Content-Type: text/xml;charset=utf-8
Content-Length: 750
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000

...
<body>
    <p>Sorry, that page doesn't exist!</p>
</body>
```

### /view-invoice

#### Introduction

To start Swift transaction use [/api/v2/auth-cash/](https://doc.payneteasy.com/integration/api_v2_auth-cash.html.md) and get receipt-id in [order status response](https://doc.payneteasy.com/integration/api_v2_status.html.md). Swift invoice in PDF is initiated through HTTPS GET request by using [URLs](#view-invoice-url) specified below. Use [HMAC-SHA1](https://doc.payneteasy.com/integration/general_api_usage/request_authentication_methods/oauth.html.md) for authentication. See [Statuses](https://doc.payneteasy.com/integration/reference/statuses.html.md).

#### API URLs

> **Note:** The path in API URL should not be hardcoded, as it may be changed in future.

| Integration | Production |
|------------------------------------------------------------------------|---------------------------------------------------------------------|
| https://sandbox.payneteasy.eu/paynet/view-invoice/ENDPOINTID/RECEIPTID | https://gate.payneteasy.eu/paynet/view-invoice/ENDPOINTID/RECEIPTID |

#### Request Example

```http
POST /paynet/view-invoice/6657/a5e8f278-8936-3286-aabb-c8960a5d04f4 HTTP/1.1
Host: sandbox.payneteasy.eu
User-Agent: curl/7.83.0
Accept: */*
Authorization: OAuth realm="",oauth_version="1.0",oauth_consumer_key="test_merch",oauth_timestamp="1687518156",oauth_nonce="EozU8eCdyBO",oauth_signature_method="HMAC-SHA1",oauth_signature="bNQNq2CLuGoOrf5eji3ffj96bC0%3D"
Content-Length: 140
Content-Type: application/x-www-form-urlencoded
Connection: close

oauth_consumer_key=test_merch
&oauth_nonce=EozU8eCdyBO
&oauth_signature_method=HMAC-SHA1
&oauth_timestamp=1687518156
&oauth_version=1.0
```

#### Success Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 23 Jun 2023 11:03:05 GMT
Content-Type: application/pdf;charset=utf-8
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
Content-Length: 34929

...
*PDF content*
```

#### Fail Response Example

```http
HTTP/1.1 200
Server: server
Date: Fri, 23 Jun 2023 12:23:15 GMT
Content-Type: application/pdf;charset=utf-8
Connection: close
X-XSS-Protection: 1
Strict-Transport-Security: max-age=31536000
Strict-Transport-Security: max-age=31536000
Content-Length: 34929

...
<body>
    <p>Sorry, that page doesn't exist!</p>
</body>
```

### Word Press / Woo Commerce

The Payneteasy Woo Commerce plugin adds Payneteasy as a payment gateway option to a
Word Press site running the Woo Commerce e-commerce plugin. Once installed and configured,
shoppers are able to pay by card during Woo Commerce checkout, with card details collected
either through an inline form on the checkout page or on a page hosted by
Payneteasy, depending on the integration mode chosen.

A live example shop running this plugin is available for reference at
[wp.codetime.net](https://wp.codetime.net/).

> **Note:** The plugin is published at [php-plugin-woocommerce](https://github.com/payneteasy/php-plugin-woocommerce), where the current release ships as an installable `wc-payneteasy.zip` package uploaded through the Word Press admin. The step-by-step walkthrough below describes the manual file-copy installation of an earlier build of the plugin; the concepts (prerequisites, credentials, sandbox testing) still apply, but the exact folder names and menu wording may differ between versions. Check the repository’s own README for the version you install.

#### Source code

The plugin source, installation guide and screenshots are maintained in the
[php-plugin-woocommerce](https://github.com/payneteasy/php-plugin-woocommerce)
repository on Git Hub.


## Merchant Documentation

### Merchant Manual

#### Introduction

This guide is intended for employees of companies which sell goods and (or) services, or perform certain work and plan to receive or make payments by bank cards or other payment methods to their Customers (referred to as Payers or Receivers). Such companies hereinafter are referred to as Merchants (or Connecting Party which represents Merchants). The documentation describes how Merchants can use the functionality of the Payneteasy software and hardware complex, as well as tracking financial flows through the Payneteasy payment business management system. Each Merchant receives a created Merchant account in Payneteasy Payment Gateway for API and UI access.

Payment facilitators which represent Merchants can receive Merchant account for represented Merchant, or Reseller account connected to Merchant accounts of each represented Merchant. Discuss the most suitable Payment Gateway accounts model with Payneteasy support manager. Reseller accounts have similar view access rights in Payment Gateway as Merchants, with the following differences:

- They can browse multiple linked Merchants,
- They can manage Reseller rate plans,
- They cannot process any transactions,
- They cannot manage Black, White and Loyalty lists,
- They cannot create new entities and notifications.

The guide is arranged according to the structure of the Payment Gateway user interface and contains detailed information about each commonly used function.

#### Quick links

Most used functionality is gathered for a quick reference:

- See all terms definitions in [Glossary](https://doc.payneteasy.com/merchant/reference/glossary.html.md),
- Discover login and user profile options on [General Account Information](https://doc.payneteasy.com/merchant/account_information.html.md) page,
- Speed up the integration to Payment Gateway with full request and response logs in [Integration panel](https://doc.payneteasy.com/merchant/tools/integration_panel.html.md),
- Create and manage dedicated accounts for each member of the team on [Employees](https://doc.payneteasy.com/merchant/settings/employees.html.md) screen,
- Sort and find transactions on [Order search](https://doc.payneteasy.com/merchant/merchant_orders.html.md) screen, see complete information about each transaction on [Order details](https://doc.payneteasy.com/merchant/merchant_orders.html.md) screen,
- Mitigate risks with [Black, White and Loyalty list](https://doc.payneteasy.com/merchant/tools/merchant_bwl.html.md) management,
- Get advanced analytics with [Dashboard](https://doc.payneteasy.com/merchant/dashboard.html.md) and [KPIs](https://doc.payneteasy.com/merchant/reference/kpi.html.md) or download detailed [reports](https://doc.payneteasy.com/merchant/reports_index.html.md) with required data in one click using templates,
- Gather data to external systems for further analysis or alerts with [additional callbacks](https://doc.payneteasy.com/merchant/settings/endpoints.html.md) for every transaction,
- Resolve ongoing payment issues with [Online monitor](https://doc.payneteasy.com/merchant/tools/tasks.html.md) and [Transaction marker notifications](https://doc.payneteasy.com/merchant/tools/transaction_marker_notification.html.md),
- Resend [multiple callbacks](https://doc.payneteasy.com/merchant/tools/batch_operations.html.md) in case of temporary handling issues of transaction results on Merchant server,
- Learn more about supported [transaction types and statuses](https://doc.payneteasy.com/merchant/reference/merchant_transaction_statuses_and_types.html.md).

Additional features might become available by request:

- Initiate transactions on UI using [Virtual terminal](https://doc.payneteasy.com/merchant/tools/virtual_terminal.html.md),
- [Capture and Cancel](https://doc.payneteasy.com/merchant/merchant_orders.html.md) preauthorized transactions and make [Refunds](https://doc.payneteasy.com/merchant/merchant_orders.html.md) on authorized ones,
- Get up-to-date information about [current balances](https://doc.payneteasy.com/merchant/settings/endpoints.html.md) and expected payout,
- Follow-up on customers with [E-mail or SMS messages](https://doc.payneteasy.com/merchant/settings/endpoints.html.md) after transactions sent from Merchant message server.

### General Account Information

Merchant employees can browse transactions and download various reports via Payneteasy UI. It is available at [production environment](https://gate.payneteasy.eu/paynet-ui/) and at [sandbox environment](https://sandbox.payneteasy.eu/paynet-ui/).

#### First Login

Upon initial access to Payneteasy UI, after logging in, the Merchant employee will be asked to create and enter a new password.

 

The minimum password length must be 8 characters. The password must contain at least one digit, one lowercase and uppercase letters and at least one special character.

> **Warning:** It is very important that the password does not consist of meaningful linguistic structures. For security reasons it is strongly recommended to use random alphanumeric values and regularly change the password.

#### Login With OTP

IF OTP (One Time Password) is enabled, an email will be sent to all users with a one-time link to create a second authentication factor.

An example of this letter:

 

Inside there is a link, by clicking on which the QR code and the secret key will be available:

To calculate the second factor, scan the QR code or enter the secret key in any available application that supports HOTP (Google Authenticator, Protectimus Smart OTP, Free OTP Authenticator and others):

 

If one-time password authentication is enabled for login, enter this password when logging in. Detailed information on working with OTP is available on the link. When logging into the system, specify a username, password and generated code from the application (each time logging in, new password from application will be required):

#### Left Menu

The menu is always located at the left-down of the screen. From up to down, here are located: the account name in Payneteasy UI and its role in the system, the current date and time in the system time zone, link to the documentation [https://doc.payneteasy.com](https://doc.payneteasy.com) with detailed information about Payneteasy UI and API, menu language and currency calculations:
 

 

To change language from header menu use the drop-down menu:

 

To change the currency for calculations in transaction monitor and dashboard, use the drop-down menu from left menu. Exchange rate is updated daily.

#### User Profile

By clicking on Merchant name on the top left side of left menu you will be redirected to user profile with two profile configuration tabs on the right side of the page: “Common” and “Orders full view settings”:

##### Common

Here you can change:

> - Name
> - Language on which system will be automatically displayed in (can be changed from the drop-down list in header menu any time)
> - E-mail address on which all configured notifications will be sent
> - Phone
> - Default currency (can be changed from the drop-down list in header menu any time)
> - Statement preview limit
> - PGP key
> - CSV delimiter - for import/export of reports and batch operations
> - Telegram Bot - register in bot on which all configured notifications will be sent
> - Mobile application - link application for notifications

##### Orders Full View Settings

In this section it is possible to configure visible fields for detailed view on Order search page:

### Batch Operations

Batch operations is the set of tools that allows to process multiple operations through the user interface of the system. Below is the list of available batch operations.

> **Note:** Additional batch operations might be provided by request

#### Resend callbacks

This batch operation can be useful if information on the final status of transactions is available in Payneteasy system and for some reason is not available in the Connecting Party system. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to send new callback notifications. An example of CSV file for upload is available on the same screen.

#### Ethoca alerts update

This batch operation can be useful for updating Ethoca statuses. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to send statuses to Ethoca system. An example of CSV file for upload is available on the same screen.

### Customers Management System

Customer Management is a huge module which allows to create a custom payment flow.

#### Parameters for CRM and PNE

customer_level - specifies level of customer for both systems.
merchant_customer_identifier - specifies customer ID in CRM.
customer_id - specifies ID in PNE.

#### Uses cases

##### CRM

| Parameters                                    | Description                                                                                                                                                                                                                                                                                                                                      |
|-----------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| customer_level                                | If only this parameter was sent, filled or empty, transaction will not pass through CRM                                                                                                                                                                                                                                                          |
| merchant_customer_identifier                  | If only this parameter was sent and such Merchant Customer ID is already created in system, transaction will pass through CRM and will attach information under such Merchant Customer ID. If such Merchant Customer ID is not registered in system, then it will pass through CRM and new Customer with all passed information will be created. |
| customer_id                                   | If only this parameters was sent and such Customer ID is already created in system, then transaction will pass through CRM, but will only attach customer level to this transaction. If such Customer ID is not registered in system then it will not pass through CRM.                                                                          |
| merchant_customer_identifier + customer_level | If both parameters are registered in system then all existing credentials will be applied. If both parameters are not registered in system before, then new customer will be created with passed credentials. If only Customer Level is registered then new user will be created and passed level will be applied to this user.                  |

### Dashboard

#### Transaction Monitor

Transaction monitor is available at the top of the page for general statistics:

 

This monitor contains the following blocks:

| `Turnover`                                                | The sum of all successful sale, capture, reversal (refund) and transfer operations   |
|-----------------------------------------------------------|--------------------------------------------------------------------------------------|
| `Declined`,   `filtered and verify`   | The number of operations of the aforementioned types with the corresponding status   |
| `Chargebacks`                                             | The number and amount of successful chargeback and prearbitration operations         |
| `Frauds`                                                  | The number and amount of successful fraud operations                                 |
| `Reversals`                                               | The number and amount of successful reversal and void operations                     |

To view the analytics detailed by each payment method, click the pointer on the right side of the relevant block:

 

#### Analytics

##### Data Scope

To change the range of statistics, use the switches:

 

Set the desired date range in the pop-up calendar:

 

Data for graphs can be sorted using the Add filter button:

 

Currencies, payment  methods, as well as endpoints, projects and other data can be specified for analysis. Here is the example of the payment method selection to construct the chart:

##### Charts bundle

 
Ratio of successful, rejected and filtered by the system transactions are displayed in the following graph:
 
 

The following graphs can be also selected by pressing the  button: the ratio by volume of transactions or by amount of payments, as well as by type of transactions (sale, capture, transfer, etc). Payneteasy Payment Gateway also displays statistics on negative activity and earnings.
 
Required time period is set by schedule switch (day, week, month):
 
 

 
Type of chart (amount, count, all) can be changed using the button:
 
 

##### Approval Ratio

The graph shows the proportions between successful, declined and filtered transactions for a selected period of time.
 
Payneteasy Payment Gateway also displays statistics per card payment system, per currency, as well as per payment method.
 
Successful Transaction Analytics for the specified period are displayed as follows:
 
 

##### Transactions By Country

Overview of analytics by country displays two types of regional statistics: based on customer IP addresses and on card BINs.
 
 

##### Transaction Decline Reasons

This statistics screen can be used for a visual assessment of the most frequent decline reasons, as well as chargeback and fraud reasons.

### Decline Statistics

This report allows to get statistics on rejected transactions, which are divided into the following groups: rejected by the acquiring bank, rejected by internal fraud system and rejected due to an internal error.
 
To download the necessary data, the following criteria are used: date range and card types. If needed, additional criteria can be added by clicking on the Criteria button: specified endpoints and projects.
 
Preview of this report can be viewed by clicking on the Preview button.
 
The Report can be generated by clicking on the the Generate button.
 
An example of the resulting report is shown below:

### Employees

#### Create Employee Account

Creating new accounts to access the system is available for merchants in “Settings” – “Employees”.
 
The Employees tab contains a list of all employees accounts, established in the system for the merchant.
 
New employee account can be created with the Add User button. The following form must be filled:
 
 

 

Next, select one of available employee roles in the system:

 

 

After the personal account is created, an employee can immediately log in. Login and password are generated at the stage of creating a personal account (do not forget to save the password beforehand). If the password was not saved, it can be reset on employee details screen.

 

 

When employee logs in to the account for the first time, the system asks to change the temporary password to a permanent one:

 

#### Edit Employee Account

All created accounts are visible on the Employees page:

 

 
The employee account is enabled.
 
The employee account is disabled.
 
 
Click on the employee’s name to open the account details, which can be changed by clicking on the Edit button. All employee account parameters, besides scope user name and login, can be changed.
 
The reset button under the user’s login is used to reset the user’s password. The system will generate a new one-time password, which should be provided to the employee. The employee then will have to change the temporary password to the permanent one on the next login to the system.
 
The search string allows to quickly find the necessary employee by ID, name, login or email:
 
 

#### User Privileges

Here are all available roles for Merchant and Reseller. Ask the Payneteasy support manager to find the most suitable roles for specific cases or get a complete list of the roles functionality.

##### Merchant

Main Merchant account has access only to his traffic and not able to see other Merchants.
 

| Employee type             | Description                                                                                                                                                                                                       |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| merchant-support          | This employee is the same as Merchant account, but not able to create Merchant employees. Can reverse orders from orders page                                                                                     |
| merchant-support-readonly | This employee is limited version of merchant-support, no access to the configuration change. Can reverse orders from orders page                                                                                  |
| merchant-risk             | This employee has access to transaction details and actions with them, view and operate with BWL lists and BWL options from order details page, Reports and Batch operations. Can reverse orders from orders page |
| merchant-risk-readonly    | This employee has access to transaction details, view and operate with BWL lists and BWL options from order details page, has no access to Reports and Batch operations                                           |
| merchant-finance          | This employee has access to view some entities in the system, Dashboard and transaction details                                                                                                                   |
| merchant-finance-readonly | This employee can see only transaction details, Batch operations and Reports                                                                                                                                      |
| merchant-vt-only          | This employee has access only to Virtual terminal                                                                                                                                                                 |
| merchant-vt-transaction   | This employee has access only to Virtual terminal and transaction details                                                                                                                                         |
| merchant-desc             | This employee can see only Dashboard and transaction details                                                                                                                                                      |
| merchant-loyalty          | This employee can see only BWL lists and transaction details                                                                                                                                                      |
| merchant-client-support   | This employee can see only transaction details                                                                                                                                                                    |
| merchant-transaction      | This employee is almost identical to merchant-client-support                                                                                                                                                      |
| merchant-analyst          | This employee is almost identical to merchant-transaction with access to Dashboard, can’t view Projects                                                                                                           |

##### Reseller

Main Reseller account has only access to see the traffic for the Projects linked to this Reseller.
 

| Employee type           | Description                                                                                                                                             |
|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| reseller-support        | This employee is the same as Reseller account, but not able to create Reseller employees                                                                |
| reseller-finance        | This employee is the same as reseller-support, but not able to deal with rate plans                                                                     |
| reseller-no-finance     | This employee is the same as reseller-support, can create employees, but no access to banking information at all                                        |
| reseller-desc           | This employee is the same as reseller-support, has access to some actions with transactions and transaction markers, but no access to Integration panel |
| reseller-client-support | This employee is the same as reseller-support, can see uploaded documents on Order details page, but no access to the Dashboard and Adjustments         |

### Endpoint Group

Endpoint group is an entity that combines several Endpoints or Master Endpoints with different currencies. The Endpoint Group simplifies the integration of a Merchant business to Payneteasy Payment Gateway when working with multiple currencies. This screen allows to view configured Endpoint Groups and their IDs.

 
To better understand the difference in integration to multiple Endpoints and Endpoint Group, see the picture below:
 
```plantuml
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 (Merchant)" #e1d5e7;line:black;line.dotted

"Connecting Party\n (Merchant)" -left-> "Endpoint\nGroup"
"Connecting Party\n (Merchant)" -down-> "layoutHelper3"
"Connecting Party\n (Merchant)" -down-> "Endpoint\n currency C"
"Connecting Party\n (Merchant)" -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 (Merchant)" -left[hidden]- "layoutHelper1"
"Connecting Party\n (Merchant)" -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
```

### Endpoints

Endpoint is uniquely identified terminal in Payment Gateway, which is assigned to the Merchant and has to be provided in the commands within Payment Gateway API.

#### Endpoint search and KPI

This screen contains all Endpoints created for the Merchant in the system:
 
 

 
The Endpoint is enabled.
 
The Endpoint is disabled.
 
 
In case of a large amount of Endpoints, search can be used:
 
 

 
In order to monitor Endpoint activity, Key Performance Indicators (KPI) are used, such as Merchant earnings and others.
 
The KPI submenu opens by pressing the Detailed button on the Endpoint search screen. See details in [KPIs Detailed View](https://doc.payneteasy.com/merchant/reference/kpi.html.md).
 
Click on the Endpoint name to open the detailed information about this Endpoint.
 

#### Endpoint details

Endpoint details screen contains information about configured options on this Endpoint, its ID, limits and linked Project. The Endpoint inherits its currency from the Project it’s linked to.
 
It is important to note that the Endpoint settings (such as limits, payment forms, client definition, etc) override the Project settings.
 
To view the filters configured on the Endpoint, use the “Fraud protection filters” tab.
 
To view the necessity of additional fields on payment form, use the “API Fields” tab.
 
To work with other configuration options, see the information below.
 

#### Message Templates

Message templates can be used to send SMS or E-mail messages to customer after each successful transaction. Merchant must provide their message server credentials to Payneteasy support manager in order to send such messages from Merchant address. Templates are created using the Template button. Example of filling the form:
 
 

 
Example of a message template in the form:
 
 

 
Message sending is enabled.
 
Message sending is disabled.
 

#### Payment Form

It is possible to configure custom payment forms on Endpoint or Master Endpoint. For configuration please see [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) in integration documentation. Provide the customized forms to Payneteasy support manager for installation. Installed form names will be visible on Endpoint details screen.

#### Callbacks

Callback can be configured at the Endpoint level by using Create Callback utility. To set up new callback, go to the bottom of Endpoint details screen and click the “Add Callback” button. There are several parameters, which can be defined in the configuration window:

* Transaction type.
* URL address - is the fully defined URL with all the parameters Merchant’s target page or script would require. Example: [https://www.merchant.com/sale_completed](https://www.merchant.com/sale_completed).
* Comment if it is required.

 
`pic68 merchant_callback`
 

#### Buy Now Button

Buy Now Button integration is relevant for Merchants who has limited portfolio of products to sell. It is the easiest way to integrate with Payneteasy. This way of integration doesn’t require much technical effort. Buy Now Button integration also allows Merchant (or Connecting Party which represents Merchant) to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted customer details form and payment form in PCI DSS certified environment.

##### Buy Now Button Setup

To configure Buy Now Button for Merchant’s website follow these instructions:

> • Find the relevant Endpoint
> • Go to Buy Now Items tab
> • Click Add item
> • Fill in the required fields.

##### Buy Now Button Required Fields

| Parameter Name   | Description                                                                                                                                                                                                                                                                              | Value                                                                                     |
|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| Amount           | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents.                                                                                                                                 | `Necessity`: Required   `Type`: Numeric   `Length`: 10    |
| Description      | The item’s description.                                                                                                                                                                                                                                                                  | `Necessity`: Required   `Type`: String   `Length`: 64k    |
| redirect_url     | The URL to the page where the Payer will be redirected after transaction is completed.                                                                                                                                                                                                   | `Necessity`: Required   `Type`: String   `Length`: 1024   |
| Destination      | Destination to where the payment goes. It is useful for Merchants who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional   `Type`: String   `Length`: 128    |
| Payment tool     | Payment methods.                                                                                                                                                                                                                                                                         | `Necessity`: Optional   `Type`: String   `Length`: 128    |

##### Buy Now Button Payment Form Fields

To configure the fields to be shown on payment form, ask Payneteasy support manager to: 1. Go to API fields on the proper Endpoint. 2. Mark each needed API field as Visible and/or Required. 3. Save API fields and preview the payment form.

> **Warning:** It is strictly advised to create separated Endpoints for Buy Now Button because activating this option might lead to errors with other types of integration. Also:

1. Buttons cannot be removed, only entire Endpoint can be disabled to stop transactions via Buy Now Button.
 
2. Transaction amount change on payment form will not be supported if any Buy Now Button is configured on this Endpoint.
 

#### Account Balance

Each Connecting Party has a merchant user account created in Payment Gateway. Merchant accounts can check current balances via Common tab on Endpoints. Balances also can be requested via API [by Endpoint](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance.html.md) or [by Merchant](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_merchant.html.md).

> **Note:** Please contact Payneteasy support to enable this feature.

See example of endpoint window with current balances below:

`balancesendpoint`

### Glossary

For the purposes of this guide, the following terms and their definitions are used:

| Payneteasy Hardware and Software System (Payneteasy Payment Gateway)   | An information system designed for automated and secure processing of payment transactions and their storage.                                                                                                                                                    |
|------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Payneteasy Payment Management System (Payneteasy UI)                   | Payment management user interface and analytical platform of Payneteasy Payment Gateway.                                                                                                                                                                         |
| Merchant                                                               | The company that provides services, works or sales of goods through the E-commerce, mobile commerce or mPOS channels.                                                                                                                                            |
| Manager                                                                | An organization that provides services for processing transactions of Processor Merchants using the Payneteasy Payment Gateway and accounting for transactions in the Payneteasy UI.                                                                             |
| Processor                                                              | The entity of the system, which is a technical integration with a specific acquiring bank or other payment service provider for processing transactions.                                                                                                         |
| Account                                                                | Identification data in the Payneteasy UI, which allows the user to interact with the system on their own behalf.                                                                                                                                                 |
| Transaction                                                            | An agreement to carry out a financial operation between a customer and the  merchant to pay for services, work or goods, to return funds for previously paid services, works or goods, to transfer money from card to card, or to hold funds for future payment. |
| Antifraud filter                                                       | Technical transaction analysis algorithm for identifying suspicious and fraudulent  transactions, based on the experience of Payneteasy employees and international fraud monitoring practices.                                                                  |
| BIN                                                                    | Bank identification number, first 6 digits of card number.                                                                                                                                                                                                       |

### Integration Panel

The screen is located in Tools – Integration Panel section. The Integration Panel displays requests sent to the system and system responses to these requests, as well as information about possible errors in the requests. This allows to quickly eliminate errors during integration. The panel also helps to view initiating requests for which, as a result of the error, orders were not created.

The following search criteria are available in Integration Panel:

- by Endpoint ID or Endpoint Group ID, to which the request was sent,
- by Order ID, assigned to transaction by Payneteasy system,
- by serial number of request and response.

Date range can also be specified for the search.

### KPIs Detailed View

#### Overview

Key Performance Indicators, or KPI, is an analysis module which helps the user to quickly visualize the detailed business related information for each main system entity - Endpoint, User, Project.
 

To view the details of the relevant element, open the respective element common screen and pick the KPIs in the dropdown Details menu. The order of KPI shown on the details view corresponds to the order in which KPIs are picked in the dropdown. The first chosen KPI is placed on the left, then goes the second etc. The user can pick up to 5 KPIs.
 
The search criteria (point 1 on the screenshot) only affect the list of elements shown and not the calculated value of the KPI.
 
The KPI value could be calculated within a time period (the control elements 2\` on the picture above). The time period is ignored when the meaning of the KPI contradicts the selected date range or in case the KPI is beside the purpose.
 
Each KPI could be used for sorting to provide the most valuable data. The user can apply the sorting by clicking the name of KPI(the control element 3 on the picture above). Please keep in mind that if KPI is selected for sorting and then removed, the sorting will still be applied.
 

#### KPIs

##### Gross Traffic

Shows: The total sum of the approved transactions of the types: sale, capture, dispute, transfer approved.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: the total sum per hour if selected date range is Today or Yesterday; the total sum per day if selected date range is This Month or previous Month.
 

`grosstraff`

Gross traffic per hour for December 7th.
 

`grosstraff2`

Gross traffic per day for November.
 

##### Earnings

Shows: earnings for the Reseller or Merchant without holds for any type of transaction in any status.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: the earnings per hour if selected date range is Today or Yesterday; the earnings per day if selected date range is This Month or previous Month.
 

`earing1`

Merchant’s earnings per hour for December 7th.
 

##### Carryover

Shows: The value of the Carryover for the current date disregarding the selected date range. Each type of user can see respective value of the Carryover.
 
Update frequency: daily at 00:00.
 
Graph: shows the carryover value staring from the selected date plus 2 months; it shows both total carryover due by the user (positive) and the carryover due to the user (negative). It also shows the carryover balance which is a sum of the two above values.
 

`carryover`

##### The Dates Of The First And Last Transactions

Shows: The date of the first and last processed transaction regardless of the date range chosen. It allows quickly finding inactive instances of the infologic model elements (Endpoints, Projects).
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: N/A
 

##### Average Transaction Amount

Shows: The average transaction amount: sale, capture, dispute, transfer in approved status. It allows to detect abnormalities when merchant changes the source of incoming payment traffic or the products sold.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: Minimal, maximal and average transaction amount per hour if selected date range is Today or Yesterday; the Minimal, maximal and average transaction amount per day if selected date range is This Month or previous Month.
 

`average1`

Minimal, maximal and average transaction amount per hour for December 7th.
 

`average2`

Minimal, maximal and average transaction amount per day for November.
 

##### Order Number Per Client Per Month

Shows: The average number of the transaction of any type and in any status for the month which falls into the selected date range. The KPI is only calculated for Endpoints and Projects. The definition of the customer is set up at the Project level, one card means one customer by default. The customer at the Endpoint differs from the customer at the Project to have an option to examine various sources of the payment traffic
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: the number of orders made by a customer per month ending by the chosen date and starting from the date of 12 months earlier.
 

`order`

The number of orders made by a customer per month. Various numbers of orders are marked by different colors . The customers who made 5-6, 7-10 and more than 10 orders are united into one group.
 

##### The Returning Clients Conversion

Shows: The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer for the month that fall into selected date range. The transaction is considered repeated for the chosen month if the customer has made a transaction at any time before. The KPI is only calculated for Endpoints and Projects. The definition of the customer is set up at the Project level, one card means one customer by default. The customer at the Endpoint differs from the customer at the Project to have an option to examine various sources of the payment traffic.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer per month ending by the chosen date and starting from the date of 12 months earlier.
 

`conversion`

The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer per month for the past year.
 

##### Transactions By Country By Client’s IP Address

Shows: The country is determined by the IP address of the customer. The transactions of any type in any status are taken into consideration. The parameter does not depend on the date range and is calculated for the lifetime.
 
Update frequency: daily at 00:45.
 
Graph: The number of transactions of any type in any status per country which is derived from the customer’s IP address for the given date range, refreshed every 10 seconds.
 

`trans_by_country`

The number of transactions for top 10 countries which are derived from the customer’s IP address
 

##### Transactions By Country By BIN

Shows: The country is derived from the customer’s card BIN. The transactions of any type in any status are taken into consideration. The parameter does not depend on the date range and is calculated for the lifetime.
 
Update frequency: daily at 00:45.
 
Graph: The number of transactions of any type in any status per country which is derived from the customer’s card BIN for the given date range, refreshed every 10 seconds.
 

`bin_country`

The number of transactions for top 10 countries which are derived from the customer’s card BIN.
 

##### Average Earnings Per Transaction

Shows: Average earnings per transaction for Reseller or Merchant without holds for any type of transaction in any status.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: Average earnings per transaction per hour if selected date range is Today or Yesterday; the Average earnings per transaction per day if selected date range is This Month or Previous Month.
 

`kpi_average_earing1`

The Merchant’s average earnings per transaction per hour for December 7th.
 

##### 3DS/non-3DS Ratio

Shows: The ratio of the number of 3DS/non-3DS sale, preauth, transfer transactions in approved, filtered and declined statuses to the total number of such transactions for the given date range.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: The ratio of the number of 3DS/non-3DS sale, preauth, transfer transactions in approved, filtered and declined statuses to the total number of such transactions for the given date range per day starting from the month’s first date to the end date of the given date range.
 
Legend:
 

`colors1`

`3d_1`

The ratio of the number of transactions in different statuses for 3DS Gate for November.
 

`3d_2`

The ratio of the number of transactions in different statuses for non-3DS Gate for November.
 

`3d_3`

The ratio of the number of transactions in different statuses for November.
 

##### 3DS/non-3DS Ratio For Declined Transactions

Shows: The ratio of the number of 3DS transactions in declined status processed with 3DS, for Enrolled cards which have MPI status Y or A to the total number of transactions of the types sale, preauth or transfer for the given period.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: The ratio of the number of 3DS/non-3DS transactions in declined status per day for the given date range starting from the month’s first date to the end date of the given date range.
 
Legend:
 

`colors2`

`3d_approve_1`

The ratio of the number of transactions in declined status with 3DS for November.
 

`3d_approve_2`

The ratio of the number of transactions in declined status with non-3DS for November.
 

`3d_approve_3`

The ratio of the number of transactions in declined status for mixed traffic for November
 

##### 3DS/non-3DS Ratio For Approved Transactions

Shows: The ratio of the number of 3DS transactions in approved status processed with 3DS, for Enrolled cards which have MPI status Y or A to the total number of transactions of the types sale, preauth or transfer for the given period.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: The ratio of the number of 3DS/non-3DS transactions in approved status per day for the given date range starting from the month’s first date to the end date of the given date range.
 

`colors2`

`3d_decline_1`

The ratio of the number of transactions in approved status with 3DS for November.
 

`3d_decline_2`

The ratio of the number of transactions in approved status with non-3DS for November.
 

`3d_decline_3`

The ratio of the number of transactions in approved status for mixed traffic for November.
 

> **Warning:** The MPI status and Enrollment status could be only determined if Payneteasy MPI plugin is being used or the Processor properly returns the data after 3DS verification.

### Master Endpoints

#### Master Endpoint Details

Master Endpoint is an entity which allows to set up Parallel form, also known as Payment Cashier. Payment Cashier hosted on Payment Gateway side can display multiple payment methods for the Payer to choose from. Master Endpoint screen allows Merchants to configure such form and select which payment methods in which order will be available to each Payer according to Payer’s country.
 
Each specific payment method is configured on a separate Endpoint, and these specifically configured Endpoints are connected to Master Endpoint. Such Endpoints, connected to Master Endpoint, are called Auxiliary Endpoints. The Master Endpoint currency is inherited from the Project it’s linked to, but Auxiliary Endpoints don’t have to be in the same currency as Master Endpoint.
 

#### Master Endpoint Configuration

In order to create Master Endpoint, go to “Settings” -> “Configuration” -> “Master endpoints” and click the “+Master Endpoint” button.
 
 

 
After selecting Master Endpoint this screen will appear:
 
 

 
Click on the To details button to view Master Endpoint itself (filters, payment form, name and etc).
 
Click on the Edit button to configure:
 
• available payment methods and their order on the form (delete, move and etc.),
 
• initiated transaction type for each payment method (sale or preauth with capture),
 
• the list of countries for each payment method to be displayed.
 
To hide or show payment method use on/off button. Turning off payment method will turn it off only for current master endpoint.
 

#### Payment Cashier Forms

It is possible to configure custom payment forms for Master Endpoint and each connected Auxiliary Endpoint. For configuration please see [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) in integration documentation. Provide the customized forms to Payneteasy support manager for installation.

### Payneteasy MCP Server

#### Introduction

A step-by-step guide to connecting the Payneteasy stateless Streamable HTTP MCP
server to Claude Desktop, Claude Code and other AI agents, authenticated with a
restricted access token.

| Key Concepts        |                                     |
|---------------------|-------------------------------------|
| Production endpoint | `https://gate.payneteasy.eu/mcp-ui` |
| Authorization       | `Authorization: Bearer <token>`     |
| Transport           | `Streamable HTTP (stateless)`       |
| Token rights        | `MCP Read Only`                     |

> **Note:** The server is **read-only**. A `MCP Read Only` token cannot mutate platform state — every exposed tool is annotated `readOnlyHint: true`.

#### MCP server URLs

Pick the endpoint that matches your environment. The configuration examples
throughout this guide use the **production** URL — replace it with the sandbox
URL when needed.

| Environment    | MCP endpoint                           | Purpose                      |
|----------------|----------------------------------------|------------------------------|
| **Production** | `https://gate.payneteasy.eu/mcp-ui`    | Live payment traffic         |
| **Sandbox**    | `https://sandbox.payneteasy.eu/mcp-ui` | Safe testing and integration |

> **Warning:** The restricted access token is issued **per environment**. Create the token in the profile of the same environment you intend to connect to. A token from one environment will not work on another.

#### Get a restricted access token

Access to the MCP server uses a Bearer token. Payneteasy uses a **restricted access
token** — it grants rights only to a selected set of operations. The
`MCP Read Only` profile is enough to connect MCP.

##### Step 1 — Open user profile

Go to the *Restricted tokens* section: Profile → Restricted tokens.

`User profile with the Restricted tokens section`

##### Step 2 — Click “Create token”

To create token, press the Create token button in the top-right corner of the Restricted tokens page.

`Restricted tokens page with the Create token button`

##### Step 3 — Fill in the token parameters

| Field            | Value                                 |
|------------------|---------------------------------------|
| Name             | any token name, e.g. `mcp-1` (1)      |
| Lifetime in days | up to `180`                           |
| Access rights    | tick the `MCP Read Only` checkbox (2) |
`Create token form with name, lifetime and MCP Read Only checkbox`

##### Step 4 — Create and copy the token

Click Create token (top-right of the form), then copy the token value and save it.

`Window with the created token and the Copy to clipboard button`

> **Warning:** The token is shown **only once**. Click Copy to clipboard and store it safely. The value cannot be viewed again. It is a long JWT string of the form `eyJ…`.

#### Claude Desktop

To connect to MCP successfully, install **Node.js** first.

##### Installing Node.js

1. Download the LTS installer for your OS from [nodejs.org](https://nodejs.org).
2. Run the installer, keeping the default options.
3. Restart the terminal (and Claude Desktop) so it picks up the new PATH.
4. Check the install:
   ```bash
   node -v
   npx -v
   ```

   Both commands should print a version number, e.g. `v20.11.0`. If
   `npx` is not found, reopen the terminal or restart the computer.

##### Configuration: via mcp-remote

**File Location**

Claude Desktop connects to remote MCP servers through a configuration file. Since
Payneteasy server uses an HTTP transport, it is added to the `mcpServers` section.

| OS      | Path                                                              |
|---------|-------------------------------------------------------------------|
| macOS   | `~/Library/Application Support/Claude/claude_desktop_config.json` |
| Windows | `%APPDATA%\Claude\claude_desktop_config.json`                     |
It can also be opened from the app: Settings → Developer → Edit Config.
 
Next **close the Claude application**.
 

> **Note:** In every configuration below, replace `<ACCESS_TOKEN>` with the value you copied. The token is sent to the server in the `Authorization: Bearer <ACCESS_TOKEN>` header.

##### claude_desktop_config.json — mcp-remote

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

##### Windows: fixing the startup issue

On Windows, launching `npx` by an absolute path often breaks because of the
space in `C:\Program Files\nodejs`. The fix is to run it through `cmd /c npx`
with a bare `npx` — it is picked up from `PATH`, so the space no longer breaks
argument parsing:

##### claude_desktop_config.json — Windows

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

That is, `command` = `cmd`, and `npx` becomes the first argument after
`/c`. The resulting command line is `cmd /c npx -y mcp-remote …`, and the
space in “Program Files” no longer matters.

> **Note:** If it still misbehaves, as a fallback specify the 8.3 short path: `"command": "C:\PROGRA~1\nodejs\npx.cmd"`. But the `cmd /c npx` variant is usually enough.

##### Configuration: via HTTP

If version of Claude Desktop does not support a direct HTTP transport, use the `mcp-remote` bridge:

##### claude_desktop_config.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

> **Note:** After saving the file, **fully restart Claude Desktop**. The connected server appears in the tools menu (the “🔌 / Search and tools” icon).

#### Claude Code

In Claude Code, MCP servers are added with a single `claude mcp add` command or
via a `.mcp.json` file in the project root.

##### Via the CLI

The fastest way is to add an HTTP server with an authorization header:

##### Terminal

```bash
# transport http, server name Payneteasy
claude mcp add --transport http Payneteasy \
  https://gate.payneteasy.eu/mcp-ui \
  --header "Authorization: Bearer <ACCESS_TOKEN>"
```

Visibility is set with the `--scope` flag:

| Scope     | Description                                   |
|-----------|-----------------------------------------------|
| `local`   | only for you in the current project (default) |
| `project` | in `.mcp.json`, shared with the team via git  |
| `user`    | available across all projects                 |

##### Checking the connection

##### Terminal

```bash
claude mcp list           # list servers and their status
claude mcp get Payneteasy # server details
```

Inside a Claude Code session, the status is checked with the `/mcp` command.

##### Via the project file

To make the server available to the whole team, add a `.mcp.json` to the
repository root. It’s best not to commit the token — move it to an environment
variable:

##### .mcp.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer ${PAYNET_MCP_TOKEN}"
      }
    }
  }
}
```

##### Terminal

```bash
export PAYNET_MCP_TOKEN="<ACCESS_TOKEN>"
```

> **Note:** Claude Code expands `${VAR}` from the environment at startup. Commit `.mcp.json` to the repository, and keep the token itself in a local `.env` / secret manager.

#### Other AI agents

The principle is the same for every client: point to the endpoint
`https://gate.payneteasy.eu/mcp-ui`, use the **Streamable HTTP** transport, and
the `Authorization: Bearer <ACCESS_TOKEN>` header. Below are concrete
configurations for popular agents.

##### Cursor

File: `~/.cursor/mcp.json` or `.cursor/mcp.json` in the project.

##### .cursor/mcp.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

Then: **Settings → MCP → Enable** for the `Payneteasy` server.

##### VS Code (GitHub Copilot / Agent Mode)

File: `.vscode/mcp.json`.

##### .vscode/mcp.json

```json
{
  "servers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

Start the server via the *Start* button above the block in `mcp.json` or with
the `MCP: List Servers` command.

##### Cline · Windsurf · other MCP clients

Most clients use a single format. If a client only supports stdio, wrap the HTTP
server with `mcp-remote`:

##### mcp settings (generic)

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

##### Manual check (curl)

Before configuring an agent, you can verify that the token works:

##### Terminal

```bash
curl https://gate.payneteasy.eu/mcp-ui \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

The response should contain the list of available tools — that means the server
and token are configured correctly.

#### Domain model

The server ships a domain model in its `instructions` field so an agent knows
how the entities relate before it calls any tool. The model is reproduced here.

##### Orders and transactions

* An **order** is a customer purchase attempt. It contains one or more
  **transactions**: pre-authorization, capture, refund, chargeback.
* Transaction statuses are **approved**, **declined** and **filtered**
  (*filtered* = blocked by fraud-prevention rules before processing).

##### Statistics tools

The `stats_*` tools return **aggregates** (counts and amounts) — never
individual orders. Use `orders_search` to find specific orders.

| Scope                            | Description                                                                                                                                                                 |
|----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| stats_get_transaction_timeseries | Returns count + amount per time bucket (day / week / month), split by transaction status.                                                                                   |
| stats_get_transaction_summary    | Returns sales / reversals / chargebacks / frauds / disputes (counts + amounts + ratios) for a date range, broken down by card type, with a grand total.                     |
| stats_get_breakdown              | Splits a metric over a date range (bar chart) by transaction status, card-issuer / IP country, or decline / chargeback / fraud reason. Same filters as the timeseries tool. |

##### Order tools

| Scope              | Description                                                                                                                                                                |
|--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| orders_get_details | Returns one order by id: the order/transaction summary, the customer’s card metadata + masked contact. Sections appear only for the order APIs the token may call.         |
| orders_search      | Finds orders by a change-date window with optional status / entity filters and paging; returns safe order summaries. Use `orders_get_details` for one order’s full detail. |

##### Resolving ids

Resolve currency / card-type ids via `refs_list_*`.

### Black, White And Loyalty Lists

#### Overview

There are 3 types of access control lists, which work as filter checks in Payment Gateway. Lists are being checked while processing the transaction when the respective filter gets applied. BWL screen is designed to manage white, black and loyalty customer lists. This screen is located in “Tools” -> “Black & White lists”. It makes the process of putting the transactions’ attributes to respective lists faster and easier. It also has quick search which helps to find the exact transaction attribute added previously.
 

In order to select entries from list, specify project for corresponding lists from dropdown menu.

It is possible to show any specific category from a certain list by clicking it in Category list to the right.

> **Note:** If it is required to migrate from old merchant account to new account, ask Payneteasy support manager to migrate existing BWL entries.

##### Black Lists

The first filter checking transaction attributes (email, IP, address, etc) is “Merchant black list”. It is possible to manage these attributes (excluding BIN) from the Order details screen. The attributes can have the following statuses:
 
 
> * attribute is in black list
> * attribute is not in black list
> * attribute is in Payneteasy black list
 

 
If any transaction attribute matches attribute in the lists and respective filter is enabled at the Project’s level, the transaction status is set to Filtered and the reason for filtering is saved in the transaction data (see [Error Codes in Transaction Filters](https://doc.payneteasy.com/integration/reference/transaction_filters.html.md) section in integration documentation).
 
For blacklisting IP addresses, it is important to note that most customers have dynamic IP which can be possessed by different customers of the same Internet provider. Mobile Internet users change IP address each time a session is created. It is also known that customers using traffic compression services (e.g. Opera Mobile) come via IP address of the proxy server provided by the service, most of which are located in Europe. According to statistics, if IP address is denied for more than 10 hours, the filtering will be in 80% cases false positive. This is why it is not recommended to filter transactions by IP without proper control. It is highly recommended prior to adding IP address into the black list to check with the Internet provider what maximal period of IP address denial can be applied. It is also important to check if the given IP address is in any third-party anti-spam systems.
 

##### White Lists

White list allows to skip additional filter checks for transactions with attributes in this list. The only attributes for whitelisting are: a card number and a customer DNA.
 
 

> **Note:** If the attribute is found in any white list the third-party fraud control systems’ checks are excluded either.

##### Loyalty Lists

Loyalty list is designed for merchants who work with the predefined set of customers. Database with customers can be managed on merchant side with PCI DSS certification, or on Payneteasy side. The system allows to manage the following several types of predefined clients lists such as names, emails, phones and etc.
 
If any transaction attribute does not match attribute in the lists and respective filter is enabled at the Project’s level, the transaction status is set to Filtered and the reason for filtering is saved in the transaction data (see [Error Codes in Transaction Filters](https://doc.payneteasy.com/integration/reference/transaction_filters.html.md) section in integration documentation).
 
One-time box can be checked for automatic removal of customer from loyalty list after their first payment.
 

#### Adding New Elements To BWL

To add new elements, click on the ADD button. The type of the added criteria will be automatically identified. Ambiguous criteria type can be manually changed, as presented below. It is also possible to use `changebutton` button to switch between source and destination.

#### Importing Lists

In order to add many attributes to one of the lists at once, use IMPORT list feature.
 

For example, in order to add card number to list, the following order should be used for every line: (5555514066237247,12,2019) with ‘,’ delimiter between lines.
 
Some lists require a country code. Full list of country and state codes for lists upload is provided in integration documentation: [country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md).
 

> **Note:** In case of disconnect or other technical problems during the process, contact technical support.

#### Exporting To File

In order to export your data into CSV file, use EXPORT to file feature.
 

The data will be parsed according to set parameters.
 
Source card number and Destination card number export will be in 6+4 format. For complete data, please contact the support service.
 

#### Available Lists For Every Role

#### Comments

When adding new records to the BWL lists, optionally, comments can be attached.
 
When adding records from order page, automatically comment will be added with transaction id.
 
In order to display comment, point a cursor on «…» next to record in the list.
 

#### Order Details: Configuring BWL Lists

The attributes can also be added and removed from BWL on order details screen, as presented below:
 
- Press ADD TO LIST and select one of the shown lists:

- After selecting any list, select the criterion by which the card will be listed:

 
Blacklisted card will be shown in black colour:
 
 

 
Whitelisted card will be shown in green colour:
 
 

 
Card in loyalty list will be shown in Payneteasy colour:
 
 

 
- Several criteria can be chosen at the same time:

 

 
- Additional criteria can be added via section as shown below:

 

 
After adding criteria via section described above, parameters will have colours depending on the selected list:

### Merchant Cashflow Report

This report calculates transaction turnovers: sale, chargeback, and reversed funds. It shows the distribution of turnover with commissions and the approximate profit for the selected period, as well as day-by-day earnings. To download the necessary data, the following criteria are used: dates, project, currencies.
 
If needed, additional criteria can be added by clicking on Criteria button: endpoints, projects.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Merchant Daily Performance Report

This report displays the day-by-day financial flow for a given period.
 
To upload the necessary data, the following criteria are used: dates, projects, currencies, card types. If needed, additional criteria can be added by clicking on Criteria button: specified endpoints and projects.
 
The report can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Orders

#### Orders Search

The “Orders search” screen displays information on all transactions processed by Payneteasy. This screen is located in the “Orders” – “Orders search” section. Related transactions are grouped in Orders. Each Order has ID assigned by Payneteasy, ID assigned by Merchant or Connecting Party which represents Merchant and ID assigned by external processor (if transaction was processed in it). For example, sale transaction and subsequent refund on this sale transaction will have the same Order ID in Payment Gateway and will be searchable by both transaction types. Orders can also be accessed from Dashboard via Quick actions.

##### Find Orders

Basic search is performed by date and exact criteria:

 

Exact criteria can be used to assist in locating a specific transaction:

| `Main`             | • merchant invoice id   • order id in Payneteasy   • processor order id   • purpose   • amount   • session token                                                                                                                               |
|--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `Customer`         | • phone   • email   • IP address   • IP address country   • billing country                                                                                                                                                                                |
| `Source Card`      | • bank name   • country   • card from order id   • BIN   • BIN range from order   • last 4   • 6+4   • approval code   • ARN   • RRN   • card holder   • card ref id   |
| `Destination Card` | • bank name   • country   • card from order id   • BIN   • BIN range from order   • last 4   • 6+4   • approval code   • ARN   • RRN   • card ref id                               |
| `Wire`             | • account number   • routing number.                                                                                                                                                                                                                                                           |
| `Card Present API` | • reader ID   • reader key serial number   • reader device serial number                                                                                                                                                                                                           |
| `Mobile API`       | • device serial number   • phone serial number   • phone IMEI                                                                                                                                                                                                                      |

The most convenient criteria to find an exact transaction are:

* 6+4 digits, which allows to most accurately search for a specific card;
* approval code and RRN (can be obtained from a bank statement or from a transfer receipt);
* transaction ID.

Additional search criteria are used to help with the selection of relevant orders list.
 
The following criteria are available:
 

| `Card types`           | allows to view transactions with a specific type of cards and payment methods;                                 |
|------------------------|----------------------------------------------------------------------------------------------------------------|
| `Currency`             | allows to select one or more currencies;                                                                       |
| `Transaction types`    | allows to view only the specified transaction types;                                                           |
| `Transaction statuses` | allows to view transactions with the specified status;                                                         |
| `Order status`         | when the transaction can’t be found, this criterion allows to track the order on all stages of its processing; |
| `Endpoint`             | allows to view all transactions on selected endpoints;                                                         |
| `Project`              | allows to view all transactions for a specific project or several projects;                                    |
| `Merchant`             | allows you to display all transactions for a specific merchant or multiple merchants;                          |
| `Error code`           | allows to view all transactions with a specific error.                                                         |
After selecting one or more search criteria, click Search.
 

##### Orders View

By default, orders in Payment Gateway are displayed as follows:
 
 

 
Orders can be presented in a brief Brief or Detailed view. This can be switched with the following button:
 
 

 
In detailed form, the orders will be displayed as follows:
 
 

 
The number of orders displayed on one page can be changed with the buttons in the “Rows” column:
 
 

 
The Date button performs sorting by date. By default the latest transactions will be displayed on top.
 

##### Download Of Selected Transactions Report

To download the sorted transactions, click one of the following buttons:
 
- download to Excel format
 
- download to CSV format.
 
An additional menu can be used to manage export fields:
 
 

 
In the pop-up window, select necessary data and save the list:
 
 

##### Order Details Screen

Order details screen is opened by сlicking on the order ID from the search screen.
 
Order details, such as IDs and order creartion time, are displayed on the left side of this screen:
 
 

 
First six and the last four digits of the card number, card expiration date and cardholder name are displayed on the card. There is also information about country, bank, card type and the payment system of the card.
 
 

 
Next to the sender and receiver cards are buttons to add card details to black, white and loyalty lists.
 
 

 
Additional customer data sent by the merchant or submitted by customer on the form is displayed under the card or other payment method indicator. Clicking on cardholder or customer data parameter (for example, e-mail address) initiates a search for all transactions with a selected parameter.
 
 

 
Click on one of the plus signs near the customer data parameter (highlighted in red on the picture) adds this parameter to black, white or loyalty list. Additional click on this sign removes the parameter from respective list:
 
 

 
All transactions within the order are grouped and the commission for each operation is calculated:
 
 

 
This screen has the functionality to leave notes. For example, notes for transaction documents, customer contacts, or any other information related to this order.
 
 

 
Current transaction status can be seen in the upper right part of order screen:
 
 

 
General information on all transactions associated with provided customer data is displayed in the top panel.
 
The total amount of all transactions made by the specified cardholder and the number of approved/declined/filtered/etc transactions:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified E-mail:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified IP address:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified card number (PAN):
 
 

##### Captures And Cancels From Back Office

If Preauth has final successful status, the Merchant can initiate cancel which cancels the deduction and returns locked amount back to customer’s card or the Merchant can initiate capture which deducts the locked amount from customer’s card. To start a cancellation or capturing (deduction) of the transaction, go to the details of the relevant order. On the order details page, click the Cancel order button for cancellation of deducting and Capture order for deducting the locked amount.

##### Refunds From Back Office

If the order has final successful status, the Merchant can return the money to the customer, on their request, for instance. To start a refund (reversal) transaction to the customer card, go to the details of the relevant order. On the order details page, click the Reverse order button.

 

The dialog box will open like presented below:

 

In this dialog box specify the amount of reversal. It can be the entire amount of the order, or only a part of it for cases where the merchant refunds payment for certain goods that are part of one order. In the Comment field a description of this refund can be added.

> **Warning:** Merchants must be extremely careful when making a refund on the order! Refund requests are immediately sent to the bank and it will not be possible to cancel this transaction from the Payneteasy system afterwards.

##### Callbacks From Back Office

If the order has final status and had server_callback_url in the initial request, the Merchant can re-send the final callback.
To send a callback to the Connecting Party, go to the details of the relevant order.
On the order details page, click the Callbacks button.

`pic52 Manager faq`

The dialog box will open like presented below:

`pic53 Manager faq`

In this dialog box click Send Again to resend the callback to the Connecting Party. If the
callback is not sent successfully, click Send Again to retry, or click Cancel to cancel the callback.

#### Recurring Payments

The screen is located in the “Orders” section.
 
This screen displays recurring payments (for example, subscriptions).
 
Basic search is performed by date and exact criteria:
 
 

 
The Criteria button contains additional search parameters:
 
 

| `Recurrence status`   | Allows to select the specified repetition status of the recurring transaction:   Failed – unsuccessful attempt;   Scheduled – planned attempt;   Stopped – currently paused or finished attempt.                                                                                                                |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `Recurrence type`     | Allows to select the specified repetition type of the recurring transaction:   Manual – recurring payments are initiated manually;   Auto – recurring payments are initiated automatically in accordance with the set schedule;   Native- recurring payments use special integration with the acquiring bank.   |
| `Endpoint`            | Allows to select the specific endpoint if there are several endpoints available.                                                                                                                                                                                                                                                                            |
| `Project`             | Allows to select the specified project if there are several projects available.   Select one or more search criteria and click Search to find the needed transactions.                                                                                                                                                                  |

#### Ethoca Alerts

This section allows to see alerts from Ethoca which helps in preventing chargebacks:

#### ChargebackHelp

This section allows to see alerts from Verifi which helps in preventing chargebacks:

### Transaction Statuses And Types

#### Transaction Types

Payneteasy Payment Gateway divides all transactions into several types, depending on the purpose of each transaction. Each transaction has a specific status.

| `sale`                 | Acceptance of  payment for provided goods  or services in a single  operation.                                                                                                                                                                                                                                                                                                                                                                                                   |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `preauth`              | Blocking of a fixed amount of money on the card for the subsequent withdrawal (financial pledge). The cardholder will not be able to use the held funds, however, this money will not be withdrawn from the bank account until a subsequent request (capture) is received from the merchant. After a certain period of time, if a follow-up request is not received from the merchant, the holding of this funds amount is cancelled and it will become available for use again. |
| `capture`              | Withdrawal of the previously held by “preauth” transaction funds from the cardholder bank account.                                                                                                                                                                                                                                                                                                                                                                               |
| `cancel`               | Cancellation of fund holding by “preauth” transaction.                                                                                                                                                                                                                                                                                                                                                                                                                           |
| `reversal`             | A refund operation for previously approved transaction (“sale” or “preauth” followed by “capture”). For example, a cancellation of an order by the customer, or a partial return of goods to the store.                                                                                                                                                                                                                                                                          |
| `transfer`             | Peer-to-peer (p2p) transfer transaction between 2 cards. This transaction can be split into 2 separate steps in some cases - card2account and deposit2card.                                                                                                                                                                                                                                                                                                                      |
| `chargeback`           | Forced refund operation initiated by the cardholder, or the issuing bank, in case of fraud.                                                                                                                                                                                                                                                                                                                                                                                      |
| `fraud`                | Special marker for fraudulent transactions.                                                                                                                                                                                                                                                                                                                                                                                                                                      |
| `retrieval`            | Request of additional documents for disputed or suspicious payment. Documents can be requested from the merchant or from their agent (service provider).                                                                                                                                                                                                                                                                                                                         |
| `account verification` | Validation of Payer’s card account information.                                                                                                                                                                                                                                                                                                                                                                                                                                  |
| `payout`               | Transfer of funds from merchant account to customer (receiver) banking account or digital wallet.                                                                                                                                                                                                                                                                                                                                                                                |

#### Transaction Statuses

All transactions are marked according to their statuses:

|       | `Approved transaction`   | The transaction was processed by the acquirer successfully (payment was made as part of the transaction). Final status.                                                          |
|----------------------------------------------|--------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|       | `Declined transaction`   | For any technical reason the acquirer cannot process the transaction. For example, this may be caused by insufficient funds on the customer card or account. Final status.       |
|       | `Filtered transaction`   | The transaction was filtered by Payneteasy Payment Gateway and was not processed. Final status.                                                                                  |
|       | `Error`                  | Processing of transaction failed. A second attempt can be made to process the transaction. If the error occurs again, contact the Payneteasy support service. Final status.      |
|     | `Unknown`                | Payment Gateway failed to get final transaction status. Contact the Payneteasy support service to clarify the transaction status. Non final status.                              |
|      | `Failed`                 | System’s internal status. It means there are no available settings to route transaction in the system due to filters or other restrictions. Final status.                        |
|  | `Processing`             | Transaction is being processed. If transaction status haven’t been changed for one hour - something went wrong, please inform Payment Gateway support service. Non final status. |
 
 

> **Note:** After reconciliation transaction status could be changed even if transaction is in final status.

### Performance Report

This report displays the financial flow for the specified period. It also allows to view the number of successful and unsuccessful transactions. Flexible criteria setting allows to get the needed data: date range and type, currencies, card types, grouping of data. If needed, additional criteria can be added by clicking on Criteria button: specified endpoints and projects.
 
Preview of the report can be viewed by clicking on the Preview button.
 
The Report can be generated by clicking on the the Generate button.
 
An example of the resulting report is shown below:

### Projects

Project is a Payment Gateway entity which determines the conditions for receiving a payment message and its further routing to the connected Processor.

#### Project search and KPI

 

This screen allows to view all Projects created in the system. In case of a large number of Projects, it may be helpful to use the search:

 
To monitor the Project activity, Key Performance Indicators (KPI) are used, such as: Merchant earnings, Average order value, and others. The KPI submenu opens by pressing the Detailed button on the Project search screen. See details in [KPIs Detailed View](https://doc.payneteasy.com/merchant/reference/kpi.html.md).
 
Click on the Project name to open detailed information about this project.
 
“Common” tab allows to see the Project characteristics and Endpoints associated with it.
 

#### Message Templates

Message templates can be used to send SMS or E-mail messages to customer after each successful transaction. Merchant must provide their message server credentials to Payneteasy support manager in order to send such messages from merchant address. Templates are created using the Template button. After pressing it, a window with new template details will open:
 
 

 

The created template will appear in the list:

Message sending is enabled.
 
Message sending is disabled.

### Reference

### Reports

Payneteasy has several reporting formats for cashflow and performance view, reconciliation and usage in external systems, as well as the ability to flexibly configure data that is displayed in reports. This section covers in detail the functionality of the system for display and download of reports in Excel and CSV format.

Payneteasy UI allows to generate the following types of reports:

| [Transaction Report](https://doc.payneteasy.com/merchant/reports/transaction_report.html.md)                                              | List of transactions for a specific period of time. This type of report is most suitable in cases where it is necessary to reconcile transactions with the bank.                                                                                                                     |
|---------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Merchant Cashflow Report](https://doc.payneteasy.com/merchant/reports/merchant_cashflow_report.html.md)                            | Calculates the turnovers and profits of the merchant date-by-date.                                                                                                                                                                                                                   |
| [Performance report](https://doc.payneteasy.com/merchant/reports/performance_report.html.md)                                              | Calculates the quantity and total volume of approved and declined transactions, reversals,  chargebacks, transactions with fraud marker, and the percentage of all unsuccessful financial transactions (declined, reversal, chargeback, fraud) in relation to approved transactions. |
| [Merchant Daily Performance Report](https://doc.payneteasy.com/merchant/reports/merchant_daily_performance_report.html.md) | This report allows to generate a summary date-by-date list of transactions with the following types: sale, reversal and chargeback.                                                                                                                                                  |
| [Decline Statistics](https://doc.payneteasy.com/merchant/reports/decline_statistics.html.md)                                              | Displays statistics on rejected transactions, divided into the following groups: rejected by the acquiring banks, rejected by Payneteasy internal fraud system and rejected due to various errors in processing, should this occur.                                                  |

### Settings

### Settings Search

The screen is designed to find projects and endpoints by their name or ID and is located in “Settings” – “Settings Search” section.

 

The search range can be specified to endpoints or projects.

### Online Monitor

#### Overview

The screen is located in “Tools” – “Monitoring” section. This screen displays information about various errors that usually require quick response, as well as the options to subscribe for notifications about any errors via Telegram, Email or Push notification. Phone number and e-mail address are taken from the personal account (Merchant or its employee account).

#### Balance Running Out

This alert is used if necessary to receive notification when the Live balance is equal or under 1000$.
 
 
`disabled scheduled adjustments`
 

#### Important Filters

Notifications can be created for cases in which transactions were filtered due to the one of the following filters:

1. Source Credit Card Number usage frequency for Email or IP address
2. Source Credit Card Number approved transaction interval
3. Total Credit Card Number usage frequency for last 24 hours (daily limit)

| Field name        | Description                                                                                                                                 |
|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| Date              | The date when alert has been created.                                                                                                       |
| ID                | Alert identification number.                                                                                                                |
| Name              | Name of the Merchant.                                                                                                                       |
| MerchantID        | Merchant identification number.                                                                                                             |
| Error Description | Triggered project filter error description with error code. Example: [1033] Too many approved transactions for the same credit card number. |
 
`disabled scheduled adjustments`

### Tools

### Transaction Marker Notification

#### Overview

The Transaction marker notification tool is used to notify users about specific issues that might happen to transactions and usually require quick response. Each time the specified transaction marker is triggered, it will send email notification to user’s email address. For example, if notifications for chargebacks are enabled, user will get a new email notification for each chargeback applied to a processed transaction. Email content can be customized.

The main screen displays a list of all notifications, their status, ID, subject, language, merchant name, message type and marker type.

#### Configuration

To add a new marker, press the Create button in the upper right corner. Notification configuration box will appear with the following parameters:
 
 

| Parameter    | Description                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                      |
|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Status       | Enabled/Disabled                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                 |
| Marker type: | * Chargeback * Chargeback after ethoca reversal * Chargeback after reversal * Duplicated chargeback * Failed cancels * Failed captures * Failed PAN eligibility * Failed payin session initiators * Failed payout session initiators * Failed reversals/refunds * Failed scorings * Fraud * Inconsistent order status * Incorrect decline code * Multiple master approvals * Phone verification * Processor callback notification * Refused payouts * Refused refunds * Retrieval * User defined |
| Merchant     | To select a merchant, enter the name or ID of the merchant                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                       |
| Subject      | All emails for this marker will have this subject                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                |
| Message type | * Email - Email with plain text. * Email (HTML) - Email with HTML support.                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                   |
| Message      | All emails for this marker will have this text message.   Transaction Marker Notification supports [Message Templates](https://doc.payneteasy.com/integration/common_utilities/receipt_message.html.md).   Additionally $!{MARKER_TYPE_NAME} was added.                                                                                                                                                                                                                                                                                             |

### Transaction Markers

Transaction markers are created to notify users about specific issues that might happen to transactions and usually require quick response or additional business process (for example, manual review or communication with the customer). This screen allows to view all created transaction markers and work with them, by adding comments to markers and set them as “processed” if the issue has been resolved. Notifications about new markers can be sent by e-mail, this functionality is configured on “Transaction Marker Notification” screen. Transaction markers can be sorted with search criteria by marker type and status. The list of markers contains information about each marker type, status and linked order ID:

### Transaction Report

This report contains the list of transactions for the specified time period. To download the necessary data, the following criteria are used: dates, date type, transaction types, change status, card types, transaction id, recurrent filter, time zone, CSV encoding. This report can also be downloaded by API for automated reconciliation or analysis: [Remote transactions report](https://doc.payneteasy.com/integration/common_utilities/reports.html.md#remote-transactions-report). Additional criteria can be added by pressing the Criteria button: order status, currency, endpoints, projects.
 
The maximum download period for report is 93 days, if data download for six months or more required, divide the required period into parts.
 

To change the template, use the template management tool:

Select criteria for this report in the following pop-up window:

After selecting the necessary parameters, enter name for the template and click on Save button. To download the report, click on the CSV button.
 
Example of the resulting table is shown below:
 
 

 

> **Note:** The returned report has wellformed CSV format. In accordance with [RFC 4180](https://datatracker.ietf.org/doc/html/rfc4180), fields containing line breaks (CRLF, CR, LF), double quotes, and commas are enclosed in double-quotes.

### Virtual Terminal

#### Overview

Virtual terminal (VT) is a technological solution that allows to process transactions from Merchant’s personal account on User Interface. This feature doesn’t require Merchant’s API integration to Payneteasy. VT immediately provides a full-featured payment manager’s workplace. VT is used for remote processing of transactions without the presence of a customer, for example, if the customer places an order or pays for services while being in another city or country. VT workflow is fully customizable in order to meet the business needs. Flexible templates will help to minimize time of filling all the customer details. The Virtual terminal supports recurring payments (by recurring ID). If the customer provided cardholder data to Payneteasy processing system before, and the Merchant registered such payment to get recurring ID, future payments can be made with recurring ID instead of cardholder data. VT also allows to generate a link for the customer to submit cardholder data in the secure environment, and, if needed, pass 3-D Secure validation.
 
 
VT provides a secure way of processing MOTO transactions with support of asymmetric cryptography. In order to do so please, [Generate A Pair Of Public And Private Keys](#public-private-keys-vt) and then pass public key to Payneteasy support and upload the private key in Browser Console ([Import Private Key To Browser Console](#import-private-keys-to-bc-vt)) or User Interface ([Import Private Key To User Interface](#private-key-to-ui-vt)).
 
The available operations for VT are:
 
 
• accepting payments from both new and previously registered customers ([Sale](#sale-vt));
 
• hold funds from both new and previously registered customers ([Preauth](#preauth-vt));
 
• transfer of funds from card to card, both for new and previously registered customers ([C2C (Card To Card) Transfer](#transfer-vt));
 
• issuance of funds to the cards of both new and previously registered customers ([D2C (Deposit To Card) Transfer](#d2c-vt));
 
• transfer of funds from one bank account to another ([Payout](#payout-vt)).
 
 
The screen is located in Tools – Virtual terminal (VT).
 
 

#### Asymmetric Cryptography

The big advantage of the new Virtual terminal is the use of an asymmetric cryptography system. Asymmetric cryptography, or public-key cryptography, is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions. Effective security only requires keeping the private key private; the public key can be openly distributed without compromising security.
 
 
The Virtual terminal becomes personalized. The user signs transaction request with his private key and the system uses the public key to verify that request is made by the owner of the corresponding private key.
 

##### Generate A Pair Of Public And Private Keys

Virtual terminal requires a pair of public and private keys from user to authorize requests. To generate it, go to [https://www.openssl.org/](https://www.openssl.org/) ( [https://slproweb.com/products/Win32OpenSSL.html](https://slproweb.com/products/Win32OpenSSL.html) ), download the latest openssl version and run the following commands:
 
 
openssl genpkey -algorithm RSA -out private_key_pkcs_8.pem -pkeyopt rsa_keygen_bits:4096
 
 
openssl rsa -pubout -in private_key_pkcs_8.pem -out public_key.pem
 
 
Please, do not share private key with anyone, it is confidential information for private use only. In contrast, public key must be passed to Payneteasy for endpoint configuration. Please use different keys for production and testing environments to avoid compromise.
 
 
PKCS #8 RSA unencrypted private key in PEM format starts with —– BEGIN PRIVATE KEY —– text. This key must be imported to Browser Console or User Interface. See details below.
 

##### Import Private Key To Browser Console

Private key is imported into browser’s IndexedDB using a script associated with the currently opened page. This script only uses plain browser APIs (WebCrypt API, IndexedDB API) and does not use any external scripts to avoid the private key being compromised.
 
Import sequence is:
 
1. Open [https://gate.payneteasy.eu/paynet-ui/login-step1](https://gate.payneteasy.eu/paynet-ui/login-step1) page in a browser(Do not login to the system).
 
2. Open the browser console. In Chrome, it is done with Ctrl+Shift+J. In Safari, it is done with Ctrl+Shift+I, Ctrl+Alt+C. For Mac - Cmd instead of Ctrl.
 
3. Replace the demo key below with real private key in PEM format (it must have **—–BEGIN PRIVATE KEY—–** prefix in the beginning).
 
```http
var privateKeyPem = `-----BEGIN PRIVATE KEY-----\
     MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDJzUVnqQhDWF2H
     pxAMcyo7f+ucIEJS3AQHG0ET/dxJ0qssGymIjdzelJ3XI+oTq2y9TTimQjtujoeh
     6zl44WrXCbJLCUDWsNjlh7hmBorpU6tJVhw1466CAxkktPJHkMqJYF0efegIfOwU
     otTzwY4tGlN6iWK0aMJ5ZWhWpZDbgap72vrRXKfCN6/JeTUdsOI7PAeZw0me04jZ
     8Lova9FVIbVzOJaFGwSUroMvXevIB8rOD57c3VCLTxE3aGNMz+9DLl6GCm8WZ1US
     HmiHybqgvGLyQswBPFcVzFgd7BpgZs+JAzYDh8ZGANvjA5F9u0b6Ynb3Mpm3+9Rl
     CtvSxKwpAgMBAAECggEAZ6+hro5KIZggjleHRm5Rz7p9S33DtiE3rJMTT/tKmV+1
     9XaLU49YYcDIjMb2OV8GAwnPRpWXRcnT5J0grXxc0do4kpdRij3ZY63lT/6ilxoX
     Uxn8aq/udPy0iYizR5QcjJNHpSgZ9WqCPmQfuJLFw2TYaYh3f6yn54n0Hzj4gd9l
     tsol4xeTKQ47c/vUF7kHfD8IYzL8jv3a3++IqzCwJ3jIpTENsBYAgrkbYN9f9GHD
     BvX3sz6tgFaYU2R8YbDvA0Yq9tVPwYrPvbhwoht6PsjE/R0UK6yqnKPEADdzWvP8
     frXmmtJ35rAymqUWfpqx9RdZ0NMR7J8ut8C5365PJQKBgQD+UidVWut7d9qvhZKq
     +T5qtasH5qkD34idFl4Ay8xsSntqTrXr7q1Ff+FQY6R+f/8IzB4ZqgnV58+8AEMc
     gJzNmkf9L119SCQDxRV/TgW2eHrUrI9XS2AI5tmyzaGY1xL4fCQQMvqNAGERT6sS
     XJRt8WjuGmE4zeqxNB0XY7u1OwKBgQDLIlnksOrPw00lWUbXHSHwdfBzjYU97KVu
     GnOl5fsCmlKanqHUfd/4StnRXpl3l56hig8mYsHV5EcfUEX98PaSbTAy8Lk5y5E9
     ye2ENOgl/IyMgHPtT6spFKm7jRmpulqG4FVCGxQl3n6/nSmztA3S1zLZzi0guI0E
     oxXCbG796wKBgC8NSgOrr5eHRClnIAyL0nVxqPPsQ+bYi3Dsu3WQPwDmAtFXQKcm
     4F3UW/5AgSV6Ttf007jR0cIGglN5BPGYBeqwGZOJGNXd6/PambCU4c+xmKASUO7I
     njrnYu2Gx9f8KqFYbl+k3uAJauwF/lOGV1vD5zLuJICa8Enap2s1Y3wTAoGBAKrx
     QnLISyIB+XbXtVyrYHdJ2Mp1Ks6cye5pBi9y5RQgqCkEG62FLCh3XOvrTvysNEs+
     slccPoBv9UYtuGjmEanRhwEnQMiZPaWgu2dJWp8081X9dxEavS/5+oghSpphf3MH
     b9gMj5z6qvE3IfPfLs7iWCGgdquVgt6HG3Wc6J53AoGAc+ZYE8kMj2p9rtu1uJgX
     +VMbbdLEUqz3BPC9Tzq+eglUlYmwUK1xynKZfkEMcu5PncaBaNLU+GmYKKgw6wZS
     soEF1KvbBB4o6nZdlGo0BirOQ0ijHDWUvtuiaaWAQoQAhQwgqqV2IOC4UfkZ6ORf
     A/UW43A9wZq9kaEgb0YWOes=\
     -----END PRIVATE KEY-----`;

// Algorithm Object
var algorithmKeyGen = {
  name: "RSASSA-PKCS1-v1_5",
  // RsaHashedKeyGenParams
  modulusLength: 2048,
  publicExponent: new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to 65537
  hash: {
    name: "SHA-256"
  }
};

function parsePem(pemString, type) {
    const expectedPrefix = "-----BEGIN " + type + "-----";
    const expectedPosftix = "-----END " + type + "-----";

    pemString = pemString.trim();
    if (!pemString.startsWith(expectedPrefix)) {
        throw "Expected PEM to start with " + expectedPrefix;
    }
    if (!pemString.endsWith(expectedPosftix)) {
        throw "Expected PEM to end with " + expectedPosftix;
    }
    const base64 = pemString.substring(expectedPrefix.length, pemString.length - expectedPosftix.length).trim();
    return Uint8Array.from(atob(base64), c => c.charCodeAt(0))
}

function parsePrivateKeyPem(pem) {
    return parsePem(pem, 'PRIVATE KEY')
}

function storePrivateKey(privateKey) {
    var request = indexedDB.open("keys");

    request.onupgradeneeded = function() {
      // The database did not previously exist, so create object stores and indexes.
      var db = request.result;
      var store = db.createObjectStore("privateKeys", {keyPath: "name"});

      // Populate with initial data.
      store.put({name: "first", key: privateKey});
    };

    request.onsuccess = function() {
      db = request.result;
    };
}

var privateKeyArray = parsePrivateKeyPem(privateKeyPem);
var NON_EXTRACTABLE = false;
window.crypto.subtle.importKey("pkcs8", privateKeyArray, algorithmKeyGen, NON_EXTRACTABLE, ['sign'])
.then(function(privateKey) {
        storePrivateKey(privateKey);
        privateKeyPem = null;
        privateKeyArray = null;
    }
);
```

4. Copy this script content and paste it into browser console.
 
5. The key has been imported in a non-extractable manner.
 
 

> **Warning:** If private key have been integrated into the browser, but it is impossible to make a transactions, please, clear browser’s cache and try again to integrate the private key.

 

> **Note:** If the proposed code is not suitable or if more information is required about the **Web Crypto API**, please visit the official site [https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API).

##### Import Private Key To User Interface

The Virtual terminal has the function of using a private key through the user interface
 
 

 
In order to faster conduct a large number of test transactions, please check the “Save key in the browser” box, and the private key will be automatically saved in the browser.
 
 

#### VT Interface Details

The VT has control buttons, which are described in more details below.
 
 

#### Template Management

1) To simplify the work of the Virtual terminal operator, data fields can be saved as a template. Using templates allows to work only with the individual attributes of the client.
 
 

 
2) After entering data on the right side of the page, it is possible to save this data as a template by clicking ‘save as a template’ and naming the new template.
 
 

 
3) To edit, clone, delete or share, click three dots near the template name and select the desired parameter. The template can be shared with users at lower levels. This way, a merchant can share the template with their employees.
 
 

 
For all selected users, the created template will become the default upon loading the virtual terminal.
 
Changes can still be made before conducting a transaction, but only the creator of the template has the authority to modify the template itself. Users with whom the template has been shared are only allowed to make copies.
 
The number of created templates available for sharing is unlimited. They will all be displayed to users in alphabetical order.
 
 

#### Transaction Specification

##### Deposit

In the deposit section, it is possible to make a Sale and a Preauth transaction, which are described below.
 

###### Sale

Sale is a type of transaction, in which customer receives goods or services from Merchant in exchange for money or other assets.
 
To initiate transaction, submit the following 3 types of information:
 
1) Transaction data - Endpoint, amount, currency, description, invoice number must be filled directly on VT.
 
2) Card info - Cardholder, Card number, Valid thru:
 
- can be filled directly on VT;
 
- can be filled automatically together with Personal info, if Recurring ID is provided. If Recurring ID is provided and CVV field is empty, use “Copy link” to provide form to customer for additional confirmation. In case if it will be filled in VT form directly then transaction will be processed directly.
 
- can be filled by customer on the form.
 
3) Personal info - First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address ,Country, etc:
 
- can be filled directly on VT;
 
- can be filled automatically together with Card info, if Recurring ID is provided;
 
- can be filled automatically, if Customer ID is provided.
 
 
Process transaction:
 
- Use “Copy link” button to generate the payment link and send it to the customer. This flow is relevant for transactions which require additional information submitted by customer on the form (cardholder data, 3DS check, etc).
 
- Use “Process” button if transaction doesn’t require any additional information submitted by customer (e.g. noCVV non3D recurring transactions).
 
 
The image shows the options available for filling.
 
 

###### Preauth

Pre authorization is a transaction type in which bank blocks the specified amount in the customer’s card account and does not allow the cardholder to use this blocked money.
 
It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).
 
To initiate transaction, submit the following 3 types of information:
 
1) Transaction data - Endpoint, amount, currency, description, invoice number must be filled directly on VT.
 
2) Card info - Cardholder, Card number, Valid thru:
 
- can be filled directly on VT;
 
- can be filled automatically together with Personal info, if Recurring ID is provided. If Recurring ID is provided and CVV field is empty, use “Copy link” to provide form to customer for additional confirmation. In case if it will be filled in VT form directly then transaction will be processed directly.
 
- can be filled by customer on the form.
 
3) Personal info - First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address ,Country, etc:
 
- can be filled directly on VT;
 
- can be filled automatically together with Card info, if Recurring ID is provided;
 
- can be filled automatically, if Customer ID is provided.
 
 
Process transaction:
 
- Use “Copy link” button to generate the payment link and send it to the customer. This flow is relevant for transactions which require additional information submitted by customer on the form (cardholder data, 3DS check, etc).
 
- Use “Process” button if transaction doesn’t require any additional information submitted by customer (e.g. noCVV non3D recurring transactions).
 
 
The image shows the options available for filling.
 

##### C2C (Card To Card) Transfer

Card-to-card transaction is a direct transfer of funds from card to card (C2C).
 
Several scenarios are possible:
 
1) Transfer money from unknown card to registered card.
 
Receiver data is retrieved using Destination Recurring ID. The receiver Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Country and other optional customer data) sections will be filled in automatically. To speed up the filling of recipient fields, use the Last used section next to “Destination recurring ID” field, which contains previously used Recurring IDs. The Merchant creates a special link for the sender with “Copy link” button. The sender receives the link to a form in which he fills his card number, expiration date, holder name and CVV, then passes the 3DS check if needed.
 
2) Transfer money from registered card to unknown card.
 
Sender data is retrieved using Recurring ID. The sender Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address, Country and other optional customer data) sections will be filled in automatically. CVV is not stored and must be requested from sender. To speed up the filling of sender fields, use the Last used section new to “Recurring ID” field, which contains previously used Recurring IDs. The Merchant creates a special link for the sender with “Copy link”. The sender receives the link to a form in which he fills the destination card number, then passes the 3DS check if needed.
 
3) Transfer money between known or registered cards.
 
The Merchant fills the cardholder data or use recurring IDs for both sender and receiver of funds directly on VT and initiates transfer processing with “Process” button. In this case the transaction must be processed through the non3D channel, which is not common for C2C transfers.
 
 

> **Note:** When filling in the Customer ID field, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.
 
 

##### Withdrawal

In the withdrawal section, it is possible to make a D2C (Deposit to card) transfer and a Payout, which are described below.
 

###### D2C (Deposit To Card) Transfer

A Deposit-to-Card transaction is a transfer of funds from a bank account to a payment card.
 
Several scenarios are possible:
 
1) Transfer money to known card.
 
The Merchant fills the cardholder data for receiver of funds directly on VT with “Process” button.
 
2) Transfer money to registered card.
 
Receiver data is retrieved using Destination Recurring ID. The receiver Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Country and other optional customer data) sections will be filled in automatically. To speed up the filling of recipient fields, use the Last used section next to “Destination recurring ID” field, which contains previously used Recurring IDs.
 
3) Transfer money to unknown card.
 
The Merchant creates a special link for the recipient of funds with “Copy link” button. The recipient receives the link to a form in which he fills the destination card number.
 
 

> **Note:** When filling in the Customer ID cell, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.
 
 

###### Payout

A Payout transaction is the disbursement of funds to a recipient account number, digital wallet or other type of account. The Merchant fills the payment data for receiver of funds directly on VT and initiates payout with “Process” button.
 
 

> **Note:** When filling in the Customer ID field, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.


## Manager Documentation

### Manager Manual

#### Introduction

Payneteasy Payment Gateway (here and hereafter System, Payment Gateway or Payneteasy) provides accepting, processing, storage and transmitting of payment data between members of payment processes. This guide is intended for managers of the Payment Gateway software and hardware complex, which enable effective processing of transactions between:

* merchants (and their facilitators),
* their end customers (referred to as Payers or Receivers),
* acquiring banks or other PSPs (or their facilitators).

Payneteasy provides a Manager account, which has broad UI and API access to the functionality of the system. This type of account allows to create and configure payment solutions for all merchants according to compliance requirements, limitations and business specifics, assign additional participants to selected merchant projects, and track financial flows of each participant.

The guide is arranged according to the structure of the Payment Gateway user interface and contains detailed information about each commonly used function.

#### Payment Gateway Objects

The hierarchy and data scope among users of the System is defined on the Simplified infological model of the System. All user roles and processing entities are described in the sections below.

##### Infological Model

```plantuml
title Simplified Infological Model of the System
class Administrator #e1d5e7;line:black;line.dotted {
}
class Superior #e1d5e7;line:black;line.dotted {
}
class Manager #e1d5e7;line:black;line.dotted {
}
class Merchant #e1d5e7;line:black;line.dotted {
}
class Reseller #e1d5e7;line:black;line.dotted {
}
class Dealer #e1d5e7;line:black;line.dotted {
}
package "Processing configuration" <<Rectangle>> {
  class Project #dae8fc;line:black;line.dotted {
  }
  class Processor #d5e8d4;line:black;line.dotted {
  }
  class Gate #f5f5f5;line:black;line.dotted {
  }
  class Endpoint #ffe6cc;line:black;line.dotted {
  }
}

Administrator -down-{ Superior
Superior --{ Manager
Manager }-left-{ Merchant
Manager }-down-{ Reseller
Manager }-right-{ Dealer
Manager --{ Project
Merchant --{ Endpoint
Endpoint }-right- Project
Reseller --{ Project
Dealer -down-{ Processor
Processor -down-{ Gate
Gate }-left- Project

hide members
hide circle
```

##### Processing Configuration

The system provides a set of integrations, named as “Processors”, with external payment institutions and payment providers. Each processor is a software module that implements a consistent communication protocol for transferring messages with external systems. To receive, process and transmit payment data, the following entities must be configured.

| Object type | Description |
|-----------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Processor | Payment Gateway entity, which incapsulates interconnection with third-party processing system. |
| Gate | A set of parameters, which identify account registered in a third-party processing system. These parameters can be used to process payment data in an external system using the messaging protocol implemented in the Processor. |
| Company | System entity which allows to combine several Gates in one entity, which can later be used in many system modules (for example limits, reports, etc.). |
| Project | System entity which determines the conditions for receiving a payment message from Endpoints and its further routing to the connected Gates. |
| Endpoint | Uniquely identified terminal, which is assigned to the Merchant and has to be provided in the commands within gateway API. |
| Endpoint group | A set of Endpoints with different currencies consolidated and available as one logical unit, which is used in gateway API URL address. |
| Master Endpoint | Additional logical unit which connects multiple Endpoints for Payment Cashier integration. |

> **Note:** Minimal configuration: 1 Processor, 1 Gate, 1 Project, 1 Endpoint.

The system allows to work with multiple currencies. Currency could be added by request.

##### User Roles

The Payment Gateway supports a dedicated account access for each user of the system. Discuss the most suitable Payment Gateway accounts model with support manager.

Each root user account can have its own Employees who can get access to the data from the root account, but with certain restrictions. Data scope is defined for all screens and reports of the system. See [Employees](https://doc.payneteasy.com/manager/settings/employees.html.md) for details.

See the list of root user accounts below:

| Merchant | Provided to the merchant’s representatives. Merchant accounts can browse their transactions and linked Projects and Endpoints. They can process transactions and manage their own restriction lists. |
|------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Manager | Provided to the representatives of PSP or payment institutions. Manager accounts have full access to the configuration of the system. |
| Superior | Provided to the representatives of multiple Managers. Superior accounts can browse and configure all entities for the linked Managers. |
| Reseller | Provided to the agents, which engage merchants for Manager. Reseller accounts can browse multiple linked Projects and Endpoints of Merchants and manage Reseller rate plans. They cannot process any transactions, manage restriction lists, or create new entities. Payment facilitators which represent Merchants can receive Merchant accounts for each represented Merchant, or a single Reseller account connected to Merchant accounts of each represented Merchant. |
| Dealer | Provided to the agents, which engage processing solutions for Manager. Dealer accounts can browse multiple Gates linked to the Processor and manage Dealer rate plans. They cannot process any transactions, manage restriction lists, or create new entities. |

#### Quick Links

Most used functionality is gathered for a quick reference:

Account management:

- Discover login and user profile options on [General Account Information](https://doc.payneteasy.com/manager/account_information.html.md) page,
- Create and manage dedicated accounts for each member of the team on [Employees](https://doc.payneteasy.com/manager/settings/employees.html.md) screen,

Basic processing configuration setup:

1. Create Merchant account.
2. Create [Gate](https://doc.payneteasy.com/manager/settings/configuration/gate/gatecreate.html.md) for selected Processor and set any bank rate plan on it.
3. Create [Project](https://doc.payneteasy.com/manager/settings/configuration/project/projectcreate.html.md) and set any manager rate plan on it, then specify the created Gate in [Routing & Balancing](https://doc.payneteasy.com/manager/settings/configuration/project/routingandbalancing.html.md) tab.
4. Create [Endpoint](https://doc.payneteasy.com/manager/settings/configuration/endpoint/endpointcreate.html.md) to link Merchant to Project, then select Available operations for this Endpoint.
5. Check that everything is connected with test transaction from [Virtual Terminal](https://doc.payneteasy.com/manager/tools/virtual_terminal.html.md).
6. Clone the Project together with Endpoints and Gates to new currency, if multiple currencies should be supported, and create [Endpoint Group](https://doc.payneteasy.com/manager/settings/configuration/manager_endpoint_group.html.md) if needed.
7. Provide Endpoint IDs per each currency and/or Endpoint Group for multi-currency integration, Merchant login, Merchant control key (for API integration), password (for UI access) to Merchant representatives.

Merchant integrations and processing assistance:

- Resend [Multiple Callbacks](https://doc.payneteasy.com/manager/tools/batch_operations.html.md) in case of temporary handling issues of transaction results on Merchant server,
- [Capture and Cancel](https://doc.payneteasy.com/manager/manager_orders.html.md) preauthorized transactions and make [Refunds](https://doc.payneteasy.com/manager/manager_orders.html.md) on authorized ones,
- Speed up the merchant integration to Payment Gateway with full request and response logs in [Integration Panel](https://doc.payneteasy.com/manager/tools/integration_panel.html.md),
- Configure follow-up on customers with [E-mail Or SMS Messages](https://doc.payneteasy.com/manager/settings/configuration/endpoint/endpointmessage.html.md) after transactions sent from message server,

Monitoring and business analysis:

- Sort and find transactions on [Orders Search](https://doc.payneteasy.com/manager/manager_orders.html.md) screen, see complete information about each transaction on [Orders Details](https://doc.payneteasy.com/manager/manager_orders.html.md) screen,
- Get advanced analytics with [Dashboard](https://doc.payneteasy.com/manager/dashboard.html.md) and [KPIs](https://doc.payneteasy.com/manager/reference/kpi.html.md) or download detailed [Reports](https://doc.payneteasy.com/manager/reports_index.html.md) with required data in one click using templates,
- Gather data to external systems for further analysis or alerts with [Additional Callbacks](https://doc.payneteasy.com/manager/settings/configuration/endpoint/endpointcallbacks.html.md) for every transaction,
- Resolve ongoing payment issues with [Online Monitor](https://doc.payneteasy.com/manager/tools/monitoring/tasks_man.html.md) and [Transaction Marker notifications](https://doc.payneteasy.com/manager/tools/transaction_monitor_markers.html.md),
- Get up-to-date information about [Current Merchant Balances](https://doc.payneteasy.com/manager/settings/users/merchant.html.md) and reflect payouts,

Learn more:

- See all terms definitions in [Glossary](https://doc.payneteasy.com/manager/reference/glossary.html.md),
- Discover all supported [Transaction Types And Statuses](https://doc.payneteasy.com/manager/reference/manager_transaction_statuses_and_types.html.md),
- Design an effective payment strategy with [Routing & Balancing](https://doc.payneteasy.com/manager/settings/configuration/project/routingandbalancing.html.md) in accordance to [Acquirer Restrictions](https://doc.payneteasy.com/manager/settings/configuration/gate/acquirerrestrictions.html.md) and [Processing Limits](https://doc.payneteasy.com/manager/tools/processing_limits.html.md),
- See options for [Fraud Protection](https://doc.payneteasy.com/manager/settings/configuration/project/fraudprotectionfilters.html.md) with more than 100 filters,
- Mitigate risks with [Black, White And Loyalty List](https://doc.payneteasy.com/manager/tools/manager_bwl.html.md) management,
- Set up Master Endpoints for [Payment Cashier](https://doc.payneteasy.com/manager/settings/configuration/manager_master_endpoint.html.md) integration,

### 3-D Secure (3DS)

3-D Secure (3DS) technology implies the pre-authentication of the participants. The particular technology supposes that the liability for authenticated transaction refusal is shifted from the internet shop to the issuer bank, then, to the cardholder. In the 3-D Secure technology, the transactions require the special password known only to the customer (cardholder) and to the issuer bank. This allows to reduce the number of Internet transaction refusals.

3-D Secure is based on the Tree-Domain Model in which the process of online transaction authentication is subdivided into three domains: Issuer Domain, Acquirer Domain and Interoperability Domain.

Issuer Domain includes: bank that issued the credit card, Access Control Server (ACS), customer intending to make a purchase by credit card, software on the customer computer (Web Browser).

Acquirer Domain includes: merchant or Internet shop (whose WEB-site is used for the purchase), Internet shop server software which creates and processes the payment authentication messages and acquirer – financial institution which interacts with the authorization system (such as Visa Net/Europay Payment System Net) according to the agreement concluded with the Internet shop and informs the shop of the authorization results.

Interoperability Domain. Visa or Master Card domain provides communication between customer, Internet-shop and Banks. At that, the domain ensures strict privacy of the information. To authenticate the customer, system sends an authentication request to the issuer bank. The issuer establishes connection to the customer, presents a secret phrase and inquires the customer password. Once the customer password is verified, the issuer bank generates response. Then, the acquirer bank authenticates the Internet shop.

#### 3-D Secure flow Diagram

```plantuml
    @startuml

  participant Cardholder
  participant "Merchant Application"
  participant "Payneteasy"
  box "Interoperability Domain" #LightBlue
    participant "Directory Server"
    participant "ACS Server"
  end box
  participant Acquirer
  participant Issuer

  "Acquirer" -> "Issuer": Inter\nSettlement

  Cardholder -> "Merchant Application": Shopping +\nTransaction Data
  "Merchant Application" -> "Payneteasy" : 3DS Transaction\nRequest Message
  "Payneteasy" -> "Directory Server": 3DS Enrolment\nRequest(VEReq)
  "Directory Server" -> "ACS Server": 3DS Enrolment\nRequest(VEReq)

  "ACS Server" -> "Directory Server": 3DS Enrolment\nResponse(VERes)
  "Directory Server" -> "Payneteasy": 3DS Enrolment\nResponse(VERes)

  "Payneteasy" <-> Acquirer: Payneteasy Risk Setting = Process All Transactions
  "Payneteasy" -> "Merchant Application": Transaction\nResponse Message
  "Merchant Application" ->o "Payneteasy": Get Transaction Request
  "Payneteasy" -> "Merchant Application": Payer Authentication Request(PAReq)\n Redirect Cardholder browser to ACS server page
  "Merchant Application" -> "Cardholder": Payer Authentication Request(PAReq)\n Redirect Cardholder browser to ACS server page
  "Cardholder" -> "ACS Server": 3DS Payer Authentication Request (PAReq)
  activate "ACS Server"
  "ACS Server" -> "ACS Server": Cardholder Authentication
  "ACS Server" -> "ACS Server": MHS Message
  "ACS Server" -> "Payneteasy": 3DS Payer Authentication Response(PARes)
   deactivate "ACS Server"

   "Payneteasy" <-> Acquirer: Process Transaction
   "Payneteasy" -> "Merchant Application": Transaction Response\nMessage
   "Merchant Application" ->o "Payneteasy": Get Transaction Request

@enduml
```

When Cardholder submits an order in Merchants Application the following process is triggered:
 
> * The Cardholder specifies the card number and CVV2;
> * The Merchants Application requests Payneteasy via MPI (Merchant Plugin Interface) billing system in order to get the address of ACS Server (Access Control Server) bank issuer;
> * Payneteasy system redirects the Cardholder to ACS Server bank issuer;
> * The Cardholder is authenticated at the Issuer then is redirected to the system Payneteasy with the results of authentication;
> * Payneteasy system authorizes the transaction in the Acquirer, if the result of the authentication was successful.

#### Verify Enrollment Response Error message

| Error message | Error code |
|---------------------------------------------------|--------------|
| Error message | Error code |
| Acquirer not participating | 50 |
| Merchant not participating | 51 |
| Password Missing | 52 |
| Incorrect password | 53 |
| Incorrect Common Name value in Client Certificate | 54 |

#### Verify Enrollment Response Values

| Enrollment Response | Description | VERes Status |
|----------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------|
| Authentication Available | Cardholder is enrolled, Activation During Shopping is supported, or proof of attempted authentication available. The merchant uses the URL of issuer ACS included in VERes to create the Payer Authentication Request | Y |
| Cardholder Not Participating | Cardholder Not Participating - Cardholder is not enrolled | N |
| Unable to Authenticate or Card Not Eligible for Attempts | Unable to Authenticate or Card Not Eligible for Attempts (such as a Commercial or anonymous Prepaid card) | U |

#### Issuer Authentication Results Values

| Authentication Result | Authentication Result Determined by Issuer ACS | PARes Status |
|---------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------|
| Authentication Successful | The issuer has authenticated the cardholder by verifying the password or other identity information | Y |
| Attempts Processing Performed | Authentication was not available, but functionality was available (through the issuer, the Visa Attempts Service, or a third party) to generate a proof the merchant attempted VbV authentication | A |
| Authentication Failed | The cardholder’s password (or other authentication information) failed validation, thus, the issuer is not able to authenticate the cardholder. The following are reasons to fail an authentication: * Cardholder fails to correctly enter the authentication information within the issuer-defined number of entries (possible indication of fraudulent user) * Cardholder “cancels” authentication page (possible indication of a fraudulent user) Merchants are not permitted to submit these transactions for authorization processing | N |
| Authentication Could Not Be Performed | The issuer ACS is not able to complete the authentication request – possible reasons include: * Card type is excluded from attempts (such as a Commercial Card or an anonymous Prepaid Card) * ACS not able to handle authentication request message * ACS is not able to establish an SSL session with cardholder browser * System failure that prevents proper processing of the authentication request Merchants may proceed with the above purchases as non-authenticated and retain liability if the cardholder later disputes making the purchase. These are non-Verified by Visa electronic commerce transactions When the PARes has a U and an Invalid Request Code of 55, this indicates that the Account Identifier in the PAReq did not match the value returned by the ACS in the VERes. Merchants must view this as an invalid transaction | U |

#### Visa Electronic Commerce Indicator (ECI)

| Name | ECI | Description |
|---------------------------------------------------|-------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Cardholder was authenticated | 5 | This value means that the cardholder was authenticated by the issuer by verifying the cardholder’s password or identity information. The value is returned by the ACS in the Payer Authentication Response message when the cardholder successfully passed 3-D Secure payment authentication |
| Merchant attempted to authenticate the cardholder | 6 | This value means that the merchant attempted to authenticate the cardholder, but either the cardholder or issuer was not participating. The value should be returned by the ACS in the Authentication Response message for an Attempt Response. Additionally, merchants may use an ECI 6 in the authorization request when a Verify Enrollment of N is received from the Visa Directory Server |
| Payment authentication was not performed | 7 | This value is set by the merchant when the payment transaction was conducted over a secure channel (for example, SSL/TLS), but payment authentication was not performed, or when the issuer responded that authentication could not be performed. An ECI 7 applies when either the Verify Enrollment or the Payer Authentication Response contains a U for Unable to Authenticate |

#### Master Card E-Commerce Commerce Indicator (ECI)

| Name | ECI | Description |
|---------------------------------------------------|-------|------------------------------------------------------------------------------------------|
| Merchant attempted to authenticate the cardholder | 01 | Authentication could not be completed but a proof of authentication attempt was provided |
| Cardholder was authenticated | 02 | Cardholder was successfully authenticated |

#### 3-D Secure authentication Result

| UI Information | VERes Status | PARes Status | CAVV/AAV | ECI Visa | ECI Master Card | Description | Master Card recommended Name |
|---------------------------------|----------------|----------------|------------|------------|------------------|--------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------|
| Merchant Not Secure Code-enabled | - | - | - | - | - | Merchant Not Secure Code-enabled | Merchant Not Secure Code-enabled |
| DS Error (%d) | Error | - | - | 7 | - | The merchant was unable to provide the appropriate credentials to the Directory Server | Error on VERes |
| Not Eligible | U | - | - | 7 | - | Unable to Authenticate | Unable to Authenticate |
| Not Participating | N | - | - | 6 | - | Cardholder Not Participating | Cardholder Not Participating |
| 3-D Secure Error | Y | Error | - | - | - | PARes validation failed. Merchant should not submit authorization request | Error on PARes |
| 3-D Secure Failed | Y | N | - | - | - | Authentication Failed. Merchant should not submit authorization request | Auth Failure (Secure Code failure or Signature verification incorrect) |
| 3-D Secure ACS Error | Y | U | - | 7 | - | The issuer ACS is not able to complete the authentication request | Unable to Authenticate |
| 3-D Secure Attempt | Y | A | No | - | 01 | - | Attempt (without AAV) |
| Full 3-D Secure Attempt | Y | A | Yes | 6 | 01 | Merchant attempted to authenticate the cardholder, but either the cardholder or issuer was not participating | Attempt |
| 3-D Secure Successful | Y | Y | No | - | 02 | Authentication Successful without AAV | Auth Success (without AAV) |
| Full 3-D Secure Successful | Y | Y | Yes | 5 | 02 | Authentication Successful | Auth Success |

### Customer Management System

#### Introduction

A CRM system helps businesses keep customer contact details up to date, track every customer interaction, and manage customer accounts. It is designed to help businesses improve customer relationships.
 

#### General Information

This screen can be found in “Tools” - “Customer Management System”.

### General Account Information

Manager employees can browse transactions, configure processing solutions and download various reports via Payneteasy UI. It is available at [production environment](https://gate.payneteasy.eu/paynet-ui/) and at [sandbox environment](https://sandbox.payneteasy.eu/paynet-ui/).

#### First Login

Upon initial access to Payneteasy UI, after logging in, the manager employee will be asked to create and enter a new password.

The minimum password length must be 8 characters. The password must contain at least one digit, one lowercase and uppercase letters and at least one special character.

> **Warning:** It is very important that the password does not consist of meaningful linguistic structures. For security reasons it is strongly recommended to use random alphanumeric values and regularly change the password.

#### Login With OTP

IF OTP (One Time Password) is enabled, an email will be sent to all users with a one-time link to create a second authentication factor.

An example of this letter:

Inside there is a link, by clicking on which the QR code and the secret key will be available:

To calculate the second factor, scan the QR code or enter the secret key in any available application that supports HOTP (Google Authenticator, Protectimus Smart OTP, Free OTP Authenticator and others):

 

If one-time password authentication is enabled for login, enter this password when logging in. Detailed information on working with OTP is available on the link.
When logging into the system, specify a username, password and generated code from the application (each time logging in, new password from application will be required):

#### Left Menu

The menu is always located at the left-down of the screen:
 
 

 

From up to down, here are located: the account name in Payneteasy UI and its role in the system, the current date and time in the system time zone, link to the documentation [https://doc.payneteasy.com](https://doc.payneteasy.com) with detailed information about Payneteasy UI and API, menu language and currency calculations.

#### User Profile

By clicking on Manager name on the top left side of header you will be redirected to user profile where you can setup your profile.
From the right side of page you will see to pages Common and Orders full view settings:

##### Common

Here you can change:

> - Name
> - Language on which system will be automatically displayed in (possible to change from the drop-down menu at the top of the page any time)
> - E-mail address on which all configured notifications will come
> - Phone
> - Default currency (possible to change from the drop-down menu at the top of the page any time)
> - Statement preview limit
> - PGP key
> - CSV delimiter
> - Telegram Bot - from this telegram bot you will receive information about all configured activities
> - Mobile application
> - Menu view

To change language from the left-bottom menu use the drop-down menu

 

To change the currency for calculations in transaction monitor and dashboard, use the drop-down menu from header menu. Exchange rate is updated daily.

##### Orders Full View Settings

In this section it is possible to configure visible fields for detailed view in orders:

### Acquirer restrictions

#### Gate level

This functionality allows to set internal filters and prevent non-successful processing of transactions on gates which have specific limitations. To switch these limitations on, go to the required gate and click on the “Acquirer restrictions” tab.

> **Warning:** If the restriction on the gate is triggered, this gate is removed from balancing block in processing strategy for the current transaction.

Information and reason codes about gates which were excluded from balancing due to triggered restrictions is displayed in transaction details on UI:

API response text for these restrictions can be found on Internal Errors page in Integration section.

There are such restrictions as:
 
 

| Restriction Name | Comment | UI code |
|--------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| Whitelist check (WL) | Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for the exact Source card number by manager and the exact Device fingerprint by manager. | |
| Predefined loyalty lists check | Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out. | 15034 15035 15036 15037 |
| Automatic loyalty lists check | This filter allows to specify a set of gates (group name) and create subsets of gates (financial instruments) within this set scope to allow processing of transactions with card numbers only on linked subsets of gates. Each card number which is processed by one of the gates within the set (group name) for the first time is linked to the subset (financial instrument) of the gate used for processing. All new transactions with the same card number will be allowed to process only on gates with the linked financial instrument and filtered on all other gates with different financial instruments within the same group name set. If the group name or financial instrument is not indicated on the gate, this filter will not be applied (even if it’s enabled). | 15110 |
| Automatic customer email loyalty lists check | This filter allows to specify a set of gates (group name) and create subsets of gates (financial instruments) within this set scope to allow processing of transactions with e-mail only on linked subsets of gates. Each e-mail which is processed by one of the gates within the set (group name) for the first time is linked to the subset (financial instrument) of the gate used for processing. All new transactions with the same e-mail will be allowed to process only on gates with the linked financial instrument and filtered on all other gates with different financial instruments within the same group name set. If the group name or financial instrument is not indicated on the gate, this filter will not be applied (even if it’s enabled). | 15110 |
| Destination Credit Card type check | This referral list allows to block transactions processing for selected Destination Credit Card types (Business, Corporate, etc.) | 15170 |
| Source Credit Card type check | This referral list allows to block transactions processing for selected Source Credit Card types (Business, Corporate, etc.) | 15171 |
| Check client approve count for merchant | This check fires when the number of transactions associated with exact client for that merchant does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 15172 |
| Check client approve count for manager | This check fires when the number of transactions associated with exact client for that manager does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 15173 |
| Check client approve date for manager | This check fires if the client’s date since their first approved transaction is below the required number of days. The client will be identified by client definition set on endpoint/project level where endpoint overrides project setting. Counts Preauth, Sale, Transfer, Payout transactions in the approved status. | 15176 |
| Source Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15004 15005 |
| Source Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15002 15003 |
| Source Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 15000 15001 |
| Source Credit Card Number usage frequency for last 3 months | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in the approved status. | 15075 15076 |
| Source Credit Card Number usage frequency for last 6 months | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in the approved status. | 15077 15078 |
| Source Credit Card Number usage frequency for last 12 months | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in the approved status. | 15079 15080 |
| Purpose usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15016 15017 |
| Purpose usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15014 15015 |
| Purpose usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 15012 15013 |
| Email usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15010 15011 |
| Email usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 15008 15009 |
| Email usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 15006 15007 |
| Visa Preauthorized Transaction Decline Response requirements | This check fires for recurring transactions only. Merchants that receive a decline response for a preauthorized transaction will only be allowed to resubmit it for authorization up to four times within 13 calendar days from the date of the original decline response for the same acquirer if the response code is one of the following: - Response Code 05 - Authorization Declined - Response Code 51 - Insufficient Funds - Response Code 61 - Exceeds Approval Amount Limit - Response Code 65 - Exceeds Withdrawal Frequency Limit If an approval response is not received within this time frame, merchants must not resubmit the transaction or their acquirers may be subject to non-compliance actions, as outlined in the Visa Rules, and may be subject to chargebacks. Visa Rules to prohibit acquirers and their recurring services merchants from resubmitting a declined transaction for authorization if it receives a pickup response: - Response Code 04 - Pick Up Card - Response Code 07 - Pick Up Card, Special - Response Code 33 - Expired Card, Capture - Response Code 34 - Suspected Fraud, Retain Card - Response Code 35 - Card Acceptor, Contact Acquirer, Retain Card - Response Code 36 - Restricted Card, Retain Card - Response Code 37 - Contact Acquirer Security Department, Retain Card - Response Code 41 - Lost Card - Response Code 43 - Stolen Card - Response Code 67 - Capture Card or a decline response of - Response Code 14 - Invalid Account Number (No Such Number) - Response Code 54 - Expired Card - Response Code 57 - Transaction Not Permitted. The time threshold is a moving window calculated backwards from the moment of the transaction. Counts Account verification, Sale, Preauth or Transfer transactions in Declined status for listed decline reasons. Correct decline reasons should be supported by a connected PSP. Limits are calculated separately per gate descriptor and not per gate. | 15023 - CANCEL 15024 - CANCEL 15025 - PICKUP 15026 - DELAY |
| Entire Email usage frequency for last 24 hours (entire daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15042 15043 |
| Entire Email usage frequency for last 7 days (entire weekly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15044 15045 |
| Entire Email usage frequency for last month (entire monthly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. | 15046 15047 |
| Entire Purpose usage frequency for last 24 hours (entire daily limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15048 15049 |
| Entire Purpose usage frequency for last 7 days (entire weekly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15050 15051 |
| Entire Purpose usage frequency for last month (entire monthly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. | 15052 15053 |
| Entire Source Credit Card Number usage frequency for last 24 hours (entire daily limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15054 15055 |
| Entire Source Credit Card Number usage frequency for last 7 days (entire weekly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in any status. | 15056 15057 |
| Entire Source Credit Card Number usage frequency for last month (entire monthly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in any status. | 15058 15059 |
| Entire Source Credit Card Number usage frequency for last 3 months (entire 3 months limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 3 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 3 months. Counts Sale, Preauth or Transfer transactions in any status. | 15081 15082 |
| Entire Source Credit Card Number usage frequency for last 6 months (entire 6 months limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 6 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 6 months. Counts Sale, Preauth or Transfer transactions in any status. | 15083 15084 |
| Entire Source Credit Card Number usage frequency for last 12 months (entire 12 months limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a window of last 12 calendar months, starting from current month. For window calculation all transaction dates are truncated to months. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 12 months. Counts Sale, Preauth or Transfer transactions in any status. | 15085 15086 |
| Source Credit Card Number usage frequency for Destination Credit Card Number | This check fires when the number of Source Credit Cards associated with exact Destination Credit Card number exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Transfer transactions in approved or declined status for the current Gate. | 15072 |
| Declined Email usage frequency for last 24 hours (decline daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 15066 |
| Declined Email usage frequency for last 7 days (decline weekly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 15068 |
| Declined Email usage frequency for last month (decline monthly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in declined status. | 15070 |
| Source Credit Card Number declined transactions count per period | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15125 15126 |
| Source Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined or Filtered status. | 15073 15074 |
| Source Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 7 days. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15128 15129 |
| Source Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15130 15131 |
| Destination Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status. | 15132 15133 |
| Destination Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status. | 15134 15135 |
| Destination Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status. | 15136 15137 |
| Total Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15138 15139 15140 15141 |
| Total Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15142 15143 15144 15145 |
| Total Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15146 15147 15148 15149 |
| Source Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15150 15151 |
| Destination Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status. | 15152 15153 |
| Total Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15154 15155 15156 15157 |
| Purpose usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15158 15159 |
| Email usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15160 15161 |
| IP address usage frequency for last N days | This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15162 15163 |
| Fingerprint usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15164 15165 |
| Account Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 15166 15167 |
| Detecting and preventing accidental duplicate email usage | Customer request for the current gate with the same email will be filtered out. | 15185 |
| Preventing sale when the pending amount exceeds limit | This filter blocks a Sale transaction on the current gate when the total amount of that credit card’s pending Sale transactions on this gate, accumulated within the configured time period, reaches the configured amount limit (including the current transaction’s amount). The client is identified strictly by Source credit card number — each card number has its own independent limit. Only transactions of type Sale are counted, and only while they are in a pending (non-final) status; Preauth, Transfer and other transaction types, as well as already Approved, Declined or Filtered transactions, are ignored. | 15190 |
| Customer email decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact customer email exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15186 15187 |
| Customer email usage frequency for last N hours | This check fires when the number of declines associated with exact customer email exceeds the configured thresholds. The time threshold is a N hours window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 24. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N hours. This filter takes into account full hours. Counts Sale, Preauth or Transfer transactions in the declined status. | 15188 |
| Customer email declines frequency for last N hours | This check fires when the number or amount of declined transactions associated with exact customer email exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 15189 |
| Source Email declined transaction interval | This check fires when the interval for the last declined transaction associated with exact Email is less than configured thresholds. The time threshold is time window calculated backwards from the moment of the transaction. The risk fires on the transaction below the set threshold. So, if you set a threshold of 10 minutes and the last declined transaction time is 10:00:00, it fires until 10:10:01. Counts Sale, Preauth or Transfer transactions in the Declined status. | 15090 |
| Billing Country State blacklist | This filter blocks transactions whose billing address state/region matches a selected list of states within one selected country; when “Allow only states from list” is enabled, the logic inverts and only transactions from the listed states are allowed, all others being blocked. States are identified by their code (1 to 3 letters or numeric, e.g. US-CA, IN-KL, LV-JUR, FR-01) — full state names are not recognized. The filter applies to Sale, Preauth, Transfer, Payout and Account Verification transactions; if the billing state field is empty, the transaction is not filtered. | 15192 |
| BIN range usage frequency | This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds, also can specify a list of card BIN range exceptions for which checks will not be performed. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 15119 |
| Issuer country usage frequency | This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 15114 |
| Preventing transaction with the same amount | This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions. | 15113 |
| Customer IP address Country differs from Issuing Country | This risk check fires when the customer IP country different from the issuing country of the card. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. If parameter “apply for countries” is empty, filter will require strict customer country to issuer country matching for all the countries, otherwise this check will force country matching for listed countries only. For example if you setup “apply for countries” to US - check will be triggered for following country combinations US-any NonUS or any NonUS-US, but for combinations any NonUS-any NonUS and US-US the check will not fire. For card2card transactions issuer country of the source card should be equal to issuer country of the destination card, i.e. this check will be triggered for any cross-border transaction. | 15116 |
| Purpose usage frequency for last year (annual limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one year window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 100 transactions, it fires on the 101th transaction in one year. Calculation of the year can be started from the beginning of the calendar year or from the filter activation truncated to the month and -12 months. I.e. if you activated the filter on May 15, 2021, the filter will consider transactions from May 2020. Counts Sale, Preauth or Transfer transactions in the approved status. | 15117 15118 |
| Transaction number per period | This check fires when the number of transactions exceeds the configured thresholds. The maximum time threshold is a 600 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction during 600 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 15115 |
| Minimum time between transactions in the acquirer | This check fires when more than one transaction is made with same card in the same financial instrument in a time threshold (in minutes). The maximum time threshold is a 120 minutes window, calculated backwards from the moment of the first transaction. The filter takes into consideration only approved transactions. The risk fires on the second transaction with the same card during set time threshold. Counts Sale and Transfer transactions. | 15120 |
| Account Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15121 15122 |
| Account Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15123 15124 |
| Account Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15125 15126 |

Below is the example of configuration for “Email usage frequency for last month (monthly limit)” restriction.
To switch this restriction on, click on the toggle button near it’s name:

> `emailusage balancing 2.0`

This restriction supports the following settings:

> 1. The Amount limit maximum total transactions amount for the last one month for this e-mail address. Value: total amount value.
> 2. For all gates with the same descriptor – current total transactions amount or count for the last one month for this e-mail address value would be calculated and converted to current gate currency to compare with amount or quantity limit. Specify the value “Y” (Yes) instead of “N” (No) to enable. Values: Y: for all gates with the same descriptor, N: for current gate only.
> 3. The quantity limit parameter specifies the transactions quantity limits. Value: total quantity value.
> 4. Use calendar month : Value: Y/N.

The choice of “Country Identifier” will be available in the “Deny” restriction configurations.

Each country is assigned its own numerical identifier. The required country can be chosen from the list.

#### Processor level

This functionality allows to prevent non-successful processing of transactions on all gates of the same processor which have specific limitations. To switch them on, go to the required processor and click on the “Acquirer restrictions” tab. Tab will be available only for manager account and linked superiors.

> `Processor ACQ tab`
There are such restrictions as:
 
 

| Restriction Name | Comment | UI code and reason |
|----------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Whitelist check (WL) | Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for: the exact Source card number by manager, the exact Device fingerprint by manager | |
| Predefined loyalty lists check | Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out.. | 18042 - Proccessor loyal source card number check failed 18043 - Proccessor loyal destination card number check failed |
| Destination Credit Card type check | This referral list allows to block transactions processing for selected Destination Credit Card types (Business, Corporate, etc). | 18112 - Proccessor unsupported destination product type |
| Source Credit Card type check | This referral list allows to block transactions processing for selected Source Credit Card types (Business, Corporate, etc). | 18113 - Proccessor unsupported product type |
| Check client approve count for merchant | This check fires when the number of transactions associated with exact client for that merchant does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 18116 - Processor required number of approvals for merchant has not achieved |
| Check client approve count for manager | This check fires when the number of transactions associated with exact client for that manager does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 18117 Processor required number of approvals for manager has not achieved |
| Source Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. Timeframe can be set to calendar day instead of 24 hours window. | 18004 - Approved hourly amount limit reached 18005 - Approved hourly quantity limit reached |
| Source Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18002 - Approved weekly amount limit reached 18003 - Approved weekly quantity limit reached |
| Source Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18000 - Approved monthly amount limit reached 18001 - Approved monthly quantity limit reached |
| Source Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18054 - Daily decline quantity limit exceeded for the same credit card number on processor 18055 - Daily decline amount limit exceeded for the same credit card number on processor |
| Source Credit Card Number decline frequency for last 7 days (decline weekly limit) | This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 18058 - Weekly decline quantity limit exceeded for the same credit card number on processor 18059 - Weekly decline amount limit exceeded for the same credit card number on processor |
| Source Credit Card Number decline frequency for last month (decline monthly limit) | This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18060 - Monthly decline quantity limit exceeded for the same credit card number on processor 18061 - Monthly decline amount limit exceeded for the same credit card number on processor |
| Destination Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions only in the approved status. | 18032 - Destination approved hourly amount limit reached 18033 - Destination approved hourly quantity limit reached |
| Destination Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions only in the approved status. | 18030 - Destination approved weekly amount limit reached 18031 - Destination approved weekly quantity limit reached |
| Destination Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions only in the approved status. | 18028 - Destination approved monthly amount limit reached 18029 - Destination approved monthly quantity limit reached |
| Total Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18038 - Total approved hourly amount limit reached 18039 - Total approved hourly quantity limit reached |
| Total Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18036 - Total approved weekly amount limit reached 18037 - Total approved weekly quantity limit reached |
| Total Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18034 - Total approved monthly amount limit reached 18035 - Total approved monthly quantity limit reached |
| Email usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18010 - E-mail approved hourly amount limit reached 18011 - E-mail approved hourly quantity limit reached |
| Email usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18008 - E-mail approved weekly amount limit reached 18009 - E-mail approved weekly quantity limit reached |
| Email usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18006 - E-mail approved monthly amount limit reached 18007 - E-mail approved monthly quantity limit reached |
| Email usage lifetime | Allows to limit the number and amount of transactions available to an individual customer and set a limit on the processor for the ALL time of existence. Customer is determined by E-Mail. This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time period is lifetime. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction. Counts Sale, Preauth or Transfer transactions in the approved status. | 18048 - E-mail approved lifetime amount limit reached 18049 - E-mail approved lifetime quantity limit reached |
| Customer IP usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18022 - Customer IP approved hourly amount limit reached 18023 - Customer IP approved hourly quantity limit reached |
| Customer IP usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18020 - Customer IP approved weekly amount limit reached 18021 - Customer IP approved weekly quantity limit reached |
| Customer IP usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18018 - Customer IP approved monthly amount limit reached 18019 - Customer IP approved monthly quantity limit reached |
| Purpose usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18016 - Purpose approved hourly amount limit reached 18017 - Purpose approved hourly quantity limit reached |
| Purpose usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18014 - Purpose approved weekly amount limit reached 18015 - Purpose approved weekly quantity limit reached |
| Purpose usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18012 - Purpose approved monthly amount limit reached 18013 - Purpose approved monthly quantity limit reached |
| BIN range usage frequency | This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds, also can specify a list of card BIN range exceptions for which checks will not be performed. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18056 - Transaction quantity limit exceeds by BIN range on processor |
| Issuer country usage frequency | This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18053 - Transactions quantity limit exceeds by country on processor |
| Preventing transaction with the same amount | This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions. | 18052 - Same amount request on processor |
| Transaction number per period | This check fires when the number of transactions exceeds the configured thresholds. The maximum time threshold is a 600 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction during 600 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18057 - Detected transaction in the set threshold of time |
| Account Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15121 15122 |
| Account Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15123 15124 |
| Account Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 15125 15126 |
| Destination Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status. | 18068 - Daily decline amount limit exceeded for the recipient on processor 18069 - Daily decline quantity limit exceeded for the recipient on processor |
| Destination Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status. | 18070 - Weekly decline amount limit exceeded for the recipient on processor 18071 - Weekly decline quantity limit exceeded for the recipient on processor |
| Destination Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status. | 18072 - Monthly decline amount limit exceeded for the recipient on processor 18073 - Monthly decline quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18074 - Daily decline total amount limit exceeded for the sender on processor 18075 - Daily decline total quantity limit exceeded for the sender on processor 18076 - Daily decline total amount limit exceeded for the recipient on processor 18077 - Daily decline total quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18078 - Weekly decline total amount limit exceeded for the sender on processor 18079 - Weekly decline total quantity limit exceeded for the sender on processor 18080 - Weekly decline total amount limit exceeded for the recipient on processor 18081 - Weekly decline total quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18082 - Monthly decline total amount limit exceeded for the sender on processor 18083 - Monthly decline total quantity limit exceeded for the sender on processor 18084 - Monthly decline total amount limit exceeded for the recipient on processor 18085 - Monthly decline total quantity limit exceeded for the recipient on processor |
| Source Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18086 - Approved specified period amount limit reached 18087 - Approved specified period quantity limit reached |
| Destination Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status. | 18088 - Approved specified period amount limit reached, 18089 - Approved specified period quantity limit reached |
| Total Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18090 - Total specified period amount limit reached 18091 - Total specified period quantity limit reached 18092 - Total specified period amount limit reached for recipient 18093 - Total specified period quantity limit reached for recipient |
| Purpose usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18094 - Purpose approved specified period amount limit reached 18095 - Purpose approved specified period quantity limit reached |
| Email usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18096 - E-mail approved specified period amount limit reached 18097 - E-mail approved specified period quantity limit reached |
| IP address usage frequency for last N days | This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18098 - IP address approved specified period amount limit reached 18099 - IP address approved specified period quantity limit reached |
| Fingerprint usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18100 - Fingerprint approved specified period amount limit reached, 18101 - Fingerprint approved specified period quantity limit reached |
| Account Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18102 - Specified period amount limit exceeded for account number on processor 18103 - Specified period quantity limit exceeded for account number on processor |
| Customer name differs from Cardholder name | This check fires when the provided customer name does not match cardholder name. | 18120 - Customer name does not correspond to the cardholder name |
| Customer billing address Country differs from Issuing Country | This risk check is triggered when a transaction has the customer billing address country different from the issuing country of the card. If parameter “apply for countries” is empty, filter will require strict customer country to issuer country matching for all the countries, otherwise this check will force country matching for listed countries only. For example if you setup “apply for countries” to US - check will be triggered for following country combinations US-any NonUS or any NonUS-US, but for combinations any NonUS-any NonUS and US-US the check will not fire. For card2card transactions issuer country of the source card should be equal to issuer country of the destination card, i.e. this check will be triggered for any cross-border transaction. | 18121 - Customer billing address Country does not correspond to the Issuing Country |
| Processor lockout by specified declines | The filter allows locking out a Processor for Lockout period of time based on the defined Limit of declined transactions with the specific Analyzed decline codes occured for the Analyzed period of time. Once the filter is activated one can track the filter lockout activities in the Processor Logs screen. When the filter is disabled it resets current status of the Processor to unblocked despite the Lockout period remaining time. Processor logs screen is enabled by request. | 19100 - Processor lockout, decline time limit reached |
| Declined Email usage frequency for last 24 hours (decline daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 19101 - E-mail decline hourly amount limit reached 19102 - E-mail decline hourly quantity limit reached |

### Audit Events

#### Overview

The Events monitor is designed to notify about certain events in the system with push or URL notifications.

The enabled URL notification sends request to the specified URL. The Connecting Party server is expected to respond with 200 OK HTTP status, otherwise the system will try to send the same notification up to 30 times in 14 days to guarantee it’s delivery.

URL Requirements - HTTPS: 443, 8443

All events, except for “Managers”, are accessible for managers and superiors. “Managers” event is only accessible for superiors.

#### Access to control key

“Access to control key” event sends notification to the specified URL about viewing of the merchant control key by any user of the system.

An example of the received data:
 
{access_date: “2021.04.01 23:59:59”, user_name: “vp-support”, merchant_name: “new merchant name”, merchant_id: “1”, viewed_data: “merchant_control_key”}
 

| Parameter name | Type | Description |
|------------------|---------|-------------------------------------------------|
| access_date | String | Date of access |
| user_name | String | The name of the user who viewed the control key |
| merchant_name | String | Merchant’s name |
| merchant_id | Integer | Merchant’s ID |
| viewed_data | String | Viewed data |

#### Access to merchant profile

“Access to merchant profile” event sends notification to the specified URL about visiting of the merchant’s page by any user of the system.

An example of the received data:
 
{access_date: “2021.04.01 23:59:59”, user_name: “vp-support”, merchant_name: “new merchant name”, merchant_id: “1”, viewed_data: “merchant_page”}
 

| Parameter name | Type | Description |
|------------------|---------|-------------------------------------------------|
| access_date | String | Date of access |
| user_name | String | The name of the user who viewed the control key |
| merchant_name | String | Merchant’s name |
| merchant_id | Integer | Merchant’s ID |
| viewed_data | String | Viewed data |

#### Endpoints

“Endpoints” event sends notification to the specified URL about creating a new/changing endpoint status.

An example of the received data:
 
{end_point_id: “1”, end_point_name: “new endpoint name”, end_point_status: “Disabled”, end_point_rate_plan_id: null, end_point_rate_plan_name: null}
 

| Parameter name | Type | Description |
|--------------------------|---------|-------------------------------------------------------------------------------|
| end_point_id | Integer | Endpoint’s ID |
| end_point_name | String | Endpoint’s name |
| end_point_status | String | Endpoint’s status. Possible values: Enabled, Disabled |
| end_point_rate_plan_id | String | Endpoint’s rate plan ID |
| end_point_rate_plan_name | String | Endpoint’s rate plan name |

#### Endpoints first transaction

“Endpoints first transaction” event sends notification to the specified URL about first endpoint transaction.

An example of the received data:
 
{end_point_id: “1”, end_point_name: “new endpoint name”, end_point_status: “Disabled”, end_point_first_transaction_date: “2021.04.01 23:59:59”}
 

| Parameter name | Type | Description |
|----------------------------------|---------|-------------------------------------------------------------------------------|
| end_point_id | Integer | Endpoint’s ID |
| end_point_name | String | Endpoint’s name |
| end_point_status | String | Endpoint’s status. Possible values: Enabled, Disabled |
| end_point_first_transaction_date | String | Date of endpoint’s first transaction |

#### Gates

“Gates” event sends notification to the specified URL about the creation of a new/changing gate status.

An example of the received data:
 
{gate_id: “1”, gate_name: “new gate name”, gate_status: “Disabled”, gate_rate_plan_id: “10”, gate_rate_plan_name: “new gate rate plan name”}
 

| Parameter name | Type | Description |
|---------------------|---------|---------------------------------------------------------------------------|
| gate_id | Integer | Gate’s ID |
| gate_name | String | Gate’s name |
| gate_status | String | Gate’s status. Possible values: Enabled, Disabled |
| gate_rate_plan_id | String | Gate’s rate plan ID |
| gate_rate_plan_name | String | Gate’s rate plan name |

#### Managers

“Managers” event sends notification to the specified URL about the creation of a new manager.

An example of the received data:
 
{manager_id: “1”, manager_name: “new manager name”}
 

| Parameter name | Type | Description |
|------------------|---------|----------------|
| manager_id | Integer | Manager’s ID |
| manager_name | String | Manager’s name |

#### Merchant

“Merchants” event sends notification to the specified URL about the creation of a new/changing merchant’s status.

An example of the received data:
 
{merchant_id: “1”, merchant_name: “new merchant name”, merchant_status: “Disabled”}
 

| Parameter name | Type | Description |
|------------------|---------|-------------------------------------------------------------------------------|
| merchant_id | Integer | Merchant’s ID |
| merchant_name | String | Merchant’s name |
| merchant_status | String | Merchant’s status. Possible values: Enabled, Disabled |

#### Merchants first transaction

“Merchants first transaction” event sends notification to the specified URL about the first merchant transaction.

An example of the received data:
 
{merchant_id: “1”, merchant_name: “new merchant name”, merchant_status: “Disabled”, merchant_first_transaction_date: “2021.04.01 23:59:59”}
 

| Parameter name | Type | Description |
|---------------------------------|---------|-------------------------------------------------------------------------------|
| merchant_id | Integer | Merchant’s ID |
| merchant_name | String | Merchant’s name |
| merchant_status | String | Merchant’s status. Possible values: Enabled, Disabled |
| merchant_first_transaction_date | String | Date of merchant’s first transaction |

#### Processing limits

“Processing limits” event sends notification to the specified URL about creating a new/changing configuration/removing a limit.

An example of the received data:
 
{processing_limit_id: “1”, processing_limit_action_type: “created”}
 

| Parameter name | Type | Description |
|------------------------------|---------|--------------------------------------------------------------------------------------------------------------------|
| processing_limit_id | Integer | Processor’s limit ID |
| processing_limit_action_type | String | Type of the processor’s limit action. Possible values: Created, Enabled, Disabled, Deleted |

#### Processor

“Processors” event sends notification to the specified URL about the creation of a new/changing processor status.

An example of the received data:
 
{processor_id: “1”, processor_name: “new processor name”, processor_status: “Disabled”}
 

| Parameter name | Type | Description |
|------------------|---------|--------------------------------------------------------------------------------|
| processor_id | Integer | Processor’s ID |
| processor_name | String | Processor’s name |
| processor_status | String | Processor’s status. Possible values: Enabled, Disabled |

#### Projects

“Projects” event sends notification to the specified URL about the creation of a new / changing project’s status.

An example of the received data:
 
{project_id: “1”, project_name: “new project name”, project_status: “Disabled”, project_rate_plan_id: “10”, project_rate_plan_name: “new project rate plan name”}
 

| Parameter name | Type | Description |
|------------------------|---------|------------------------------------------------------------------------------|
| project_id | Integer | Project’s ID |
| project_name | String | Project’s name |
| project_status | String | Project’s status. Possible values: Enabled, Disabled |
| project_rate_plan_id | String | Project’s rate plan ID |
| project_rate_plan_name | String | Project’s rate plan name |

### Batch Operations

#### Overview

Batch operations is the set of tools that allows to process multiple operations through the user interface of the system. Below is the list of available batch operations.

#### Gate Operations

##### Close Day For Selected Gates

This batch operation can be useful for closing bank day on a group of gates. Select the gate or processor IDs in order to close bank days on all gates.

 

 

> **Note:** When processor selected, close day will be applied to all gates attached to this processor.

#### Transaction Operations

##### Chargeback

This batch operation can be useful if for some reason reversal was not made to prevent a chargeback and creating chargeback transaction according to specified input is needed. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to make chargebacks for selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Reversal

This batch operation can be useful for creating reversal transactions in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to make reversal of selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Fraud

If Connecting Party suspects transaction to be fraudulent, then this batch operation can be useful for marking transactions as fraud in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to mark selected transactions as fraud. An example of CSV file for upload is available on the same screen.

 

##### Capture

This batch operation can be useful for deducting the locked amount from preauth transactions (preauth should be in approved final status) in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to make capture of selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Retry Pending Reversals

This batch operation re-sends reversal request for pending reversals in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to make reversal of selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Blacklist

This batch operation, in according to specified input, puts cards in blacklist or external fraud system if such is set up. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to blacklist card of selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Commit Reversal

This batch operation can be useful for initiating reversal transactions in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to make reversal of selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Add Comment To Transactions

This batch operation can be useful for adding a or an additional comment to transactions in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to add comment for the selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Add Card Mappings

This batch operation can be useful for one or more cardholder identifiers to be mapped (assigning) to card data.

 

##### Query Status Of Transactions

This batch operation can be useful for requesting status of transactions (doesn’t matter in what status) in according to specified input. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to request status of the selected transactions. An example of CSV file for upload is available on the same screen.

 

##### Resend Callbacks

This batch operation can be useful if information on the final status of transactions is available in Payneteasy system and for some reason is not available in the Connecting Party system. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to send new callback notifications. An example of CSV file for upload is available on the same screen.

##### Upload Chargebacks Info

This batch operation can be useful, while chargeback procedure is ongoing, for uploading additional information about chargeback. Collect the order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to add chargebacks information.

 

##### Sale With Card Reference ID

This batch operation can be useful for initiating sale without any card information using only card reference ID. Collect the Endpoint and Card reference IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to initiate sale transactions with card reference ID. An example of CSV file for upload is available on the same screen.

 

##### Ethoca Alerts Update

This batch operation can be useful for updating Ethoca statuses. Collect the order IDs, assigned by Payneteasy system to the CSV file and upload it to send statuses to Ethoca system. An example of CSV file for upload is available on the same screen.

 

##### Create Recurring Payments

This batch operation can be useful for initiating recurring payments for transactions that require regular debits with the same data. Collect the order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to create recurring payments. An example of CSV file for upload is available on the same screen.

 

##### Update Recurring Payments

This batch operation can be useful for updating recurring payments (new customer data and etc.) for transactions that require regular debits with the same data. Collect the recurring order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to update recurring payments information. An example of CSV file for upload is available on the same screen.

 

##### PIPO Mark Sent

This batch operation allows to mark pending bank transfer as sent (but not received yet). This status equals to “processing” for preauth transaction. Collect order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to mark PIPO payments as sent. An example of CSV file for upload is available on the same screen.

 

##### PIPO Mark Received

This batch allows to mark pending bank transfer as received. This status equals to “approved” for preauth transaction. Collect order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to mark PIPO payments as received. An example of CSV file for upload is available on the same screen.

 

##### Scoring

This batch allows to get information about card scoring. Collect order IDs and needed card data, assigned by Payneteasy system and enter all information to the CSV file and upload it to receive card scoring information. An example of CSV file for upload is available on the same screen.

 

##### Retrieval

This batch operation can be useful for uploading a copy of the sales ticket to support or identify a potential chargeback. Collect the order IDs, assigned by Payneteasy system and enter all information to the CSV file and upload it to add retrieval information. An example of CSV file for upload is available on the same screen.

### Batch Operations for Gates

#### Overview

Batch Operations feature allows simultaneous management of multiple
payment gates without the need to edit each gate individually.
 
The functionality is designed to simplify administrative tasks related
to gate configuration, particularly for cases where acquirer limits or
filters must be updated across many gates at once. This functionality
is available in the “Gates” section of the user interface. It is
available for Manager and Superior roles by default, and can be added
for Employees by request.
 

Available Actions:

| Action | Description |
|-----------------------|---------------------------------------------------------------------|
| Enable/Disable Gates | Turns the selected gates ON or OFF. |
| Min/Max Amount | Sets the minimum and maximum transaction amount for selected gates. |
| Acquirer Restrictions | Allows enabling and configuring Referral and Velocity filters. |
 

#### Process Batch Operations for Gates in User Interface

1. Go to Settings -> Configuration -> Gates.
2. Use **Advanced Search** to filter gates according to specific criteria.
3. Select gates using checkboxes located in the left column of the gate list. Select all gates on the page or all filtered gates (up to 20,000).
4. Once gates are selected, use the Actions button in the upper-right corner to open the list of available batch operations.

 
`Select Gates`
 

> **Note:** Only one batch operation can run at a time. Attempts to start a new one will show the relevant warning message.

##### Enable/Disable Gates

This operation changes the activation status of multiple gates simultaneously.

Steps:
 
1. Select required gates.
 
2. Choose Actions -> Enable/Disable.
 
3. In the modal window, select the desired action (Enable or Disable).
 
4. Click Apply.
 
 
`Enable Disable Gates`

##### Min/Max Transaction Amount

Used to define minimum and maximum allowed transaction amounts for
selected gates. If the selected gates have different currencies, the
system converts the values automatically based on the current internal
exchange rate.

Steps:
 
1. Select gates.
 
2. Choose Actions -> Min/Max Amount.
 
3. In the modal window specify:
 
- Currency — selected from the list (only one currency can be applied);
 
- Min Transaction Amount;
 
- Max Transaction Amount.
 
4. Ensure that the minimum value is not greater than the maximum value.
 
5. Click Apply.
 
 
`Min Max Amount Gates`
 

> **Warning:** If the MIN or MAX value is already set at the gate level, then when applying the batch, incorrect values (for example, if MIN is greater than MAX) may be displayed as successfully applied, but will not actually be written to the gate. The display of notifications will be improved in the future.

##### Acquirer Restrictions

This function allows applying **Referral** and **Velocity** filters to a
group of gates, and configuring their specific parameters.

Steps:
 
1. Select gates.
 
2. Choose Actions -> Acquirer Restrictions.
 
3. In the modal window, check selected gates and click Next.
 
4. At the **Filters** tab, select one or more filters from the available list (Referral and Velocity).
 
5. In the right tab **Configurations**, specify filter settings:
 
- Enable/Disable switch;
 
- Choose currency;
 
- Amount and quantity limits. If the selected gates have different currencies, the system converts the values automatically based on the current internal exchange rate;
 
- Additional options (for example: *for all gates with the same descriptor*).
 
6. Hover over the i icon near each filter or parameter to view a tooltip description.
 
7. Click Apply to execute the operation.
 
 
`restrictions_1``restrictions_2``restrictions_3`

##### Task Execution and Monitoring

Each batch operation is added to the execution queue and processed
asynchronously by the backend system.

**User Interface Behavior:**

- While the batch task is running, an informational panel is displayed
 above the gate list showing:
 - Total number of gates in process
 - Current progress (percentage)
 - Count and percentage of successfully updated gates
 - Count and percentage of failed updates
- When the task completes:
 - A download link for a CSV file with failed gate updates and
 error codes appears.
 - The temporary CSV file is deleted after it’s downloaded.
 - The user can close the panel with the Close (X) button.

`excec_status`

### Construction principles of billing model

#### Overview

Starting from release 3.23.01 the revenue is distributed among all participants in hierarchical manner. It allows calculations to be more precise, to manage the hold payout parameters and to tune the rates model depending on the payment flow.
 
This kind of model allows to redefine the rates as well as the hold amount and its payout date.
 
The order of revenue distribution for the sale transactions
 

When an SMS or DMS transaction is processed all the participants withdraw their fee from the sale amount according to the rates defined. The rates applied from Bank to Merchant. Each participant in the flow can see only the rates defined for him without knowing the rates of preceding participants of the payment flow. For sale transactions the last participant is the Reseller and his rate will be the final one.
 
The order of revenue distribution for the transfer transactions
 

When the transfer transaction is being processed the rate calculation is the same, except for the additional participant – the money receiver. The last participant in this flow is the Merchant, and the receiver sees his rate as final
 

#### Rates definition

The rates are applied in increasing manner, each successive rates plan will adopt the preceding rate. Thus, the higher the user level the higher his rate is. The Bank’s and Dealer’s rates are defined at Gate level, for the others – Managers, Resellers and Merchants – at the Project level. These rates can overridden at the Endpoint level. There can be some missing participants in this flow.
 

#### Commission accounting

The first element on the diagram is the total commission accounted for the transaction. For the sake of simplicity we will examine sale transaction on the Project without Reseller. Thus the Merchant was deducted the commission defined in Manager’s rate plan. In this case the commission calculation goes throw the priority flow Bank → Dealer → Manager. That means that the Bank is the first to get its share according to the Bank’s rate, then the Dealer’s commission will be deducted and the Manager takes the rest.
 

There is a probability that the commission would not match the expected one.

*Example 1:*
 
Let’s see how the calculation of the commission would change depending on the ranges applied.
 
> * The Dealer’s rate plan is denied as follows: if the transaction amount is between 0 and 1000 USD, the Dealer’s rate is 5 USD, if greater than 1000 USD – 8 USD;
> * The Manager’s rate is fixed: 10 USD;
Let’s assume that the Manager didn\`t notice the ranges defined by the Dealer and expects the commission of 5 USD
 

As you can see on the picture the Dealer’s commission is calculated before Manager’s and the actual Manager’s commission will be lower the expected – 2 USD.
 
*Example 2:*
 
You should be much more careful with the rates defined for BIN, country or bank Let’s assume that the Dealer’s and Manager’s ranges are the same.
 
> * Dealer’s rate: for all the transactions 5 USD, except for BIN 233445 which has the rate of 12 USD;
> * Manager’s rate: let’s assume that the Manager’s didn’t take into account the Dealer’s rate for the BIN and defined the fix rate of 10 USD.
Let’s examine the transaction with the BIN 456778. The total commission will be distributed in the following way: 5 USD for the Dealer, 5 USD for the Manager.; The transaction with the BIN 233445 makes 12 USD for the Dealer and the Manager’s commission will be negative: -2 USD, because the total commission in the Manager’s rate plan is 10 USD.
 

#### The hold and its carryover

In order to insure the risks carried by the Merchant it is possible to define the hold for particular Merchants. The payout management system provides the accounting of frozen holds and the amount of holds that are due to be paid back to the Merchant. The hold covers the risks related to chargebacks initiated by unhappy customers in case the contract with the Merchant was canceled. The carryover operation is accomplished during no more than 182 calendar days. The payment period as well as the hold percentage is defined in the rates.
 
The algorithm of the hold calculation and carryover
 
Every participant of the payment flow, except for the Merchant, can define his own the hold percentage and the hold period. The hold percentage and hold period do not depend on each other.
 

According to the figure, for the transaction t1 the Bank withdraws from the value of HB from the total commission for the period of ΔtB, defined in the Bank’s rate. Thus the Bank holds the amount of HB for the period [t1, t2] on its account to cover the risks of chargeback and fraud operations. After ΔtB period has expired, in case the were no negative transactions the Bank pays out the hold back to the Dealer. This process CB is known as carryover. The same flow is applied to any participant of the payment flow.
 

The total earnings of any participant is: commission + hold of the participant – hold of preceding participant.

> * For the Bank: in the moment t1 for the period ΔtB the earnings will be topped up by the amount of the hold HB, in the moment t2 will be deducted the same amount;
> * For the Dealer: in the moment t1 for the period ΔtD the earnings will be topped up by the amount of the hold HD, in the moment t3 will be deducted the same amount, in the moment t2 the Dealer’s earnings are topped up by the amount of the carryover CB paid back by the Bank
> * For the Manager: in the moment t1 for the period ΔtM the earnings will be topped up by the amount of the hold HM, in the moment t4 will be deducted the same amount, in the moment t3 the Manager’s earnings are topped up by the amount of the carryover CD paid back by the Dealer
> * For the Reseller: in the moment t1 for the period ΔtR the earnings will be topped up by the amount of the hold HR, in the moment t5 will be deducted the same amount, in the moment t4 the Reseller’s earnings are topped up by the amount of the carryover CM paid back by the Manager
> * For the Merchant: the Merchant cannot define the hold values, in the moment t1 for the period ΔtR the earnings will be deducted the amount of the hold HR, in the moment t5 will be topped up by the same amount
If you define the hold parameters in the correct way the hold percentage of the payment flow participant is not less than the hold percentage of the preceding participant. Otherwise it leads to financial risks. The same is true for the hold period parameter.
 

#### Rates validation

Starting from the release 3.23.0 you can define negative rates. It is not possible to validate the rate plans at the time of creation and the validation is carried out at the time of transaction processing. If the negative rates were defined deliberately you should turn off the validation in the Project settings. This will switch off the validation for all the rates defined for the Project.
 

#### Event model

Payneteasy uses event model to apply the rates. The Processors generate various events. The rates are applied to those events according to the rate plans. Payneteasy associate the event with the transaction in the system whether it’s sale transaction or an external fraud system call. The transaction is the minimal unit of tariffing. The transaction has type and status.
 

##### Standard transaction types

| Transaction | Description |
|---------------|---------------------------------------------------------------------------------------------------|
| sale | withdraws the amount from the client’s account |
| preauth | holds the amount on the client’s account but doesn’t withdraw |
| capture | captures the amount from the client’s account, can be only issued after the respective preauth |
| cancel | cancels the preauth transaction, if it has not been captured by capture operation |
| reversal | returns the amount back to the client’s account |
| chargeback | the request to charge back the amount initiated by the cardholders via the issuing bank |
| dispute | to contest the chargeback operation, confirms the double withdrawal |
| fraud | the operation marks the transaction as fraudulent |
| refund | the operation to debit the client’s account directly |
| transfer | the money transfer operation, transfer the money between the cards or from the Merchant’s account |

##### Standard transaction statuses

| Transaction | Description |
|---------------|---------------------------------------------------------------------------------|
| approved | the transaction is approved by the Bank or PSP |
| decline | the transaction is declined by the Bank or PSP |
| filtered | the transaction is filtered out by the system before it reached the Bank or PSP |
The current model allows the following combinations of types and statuses:
 
> * APPROVED: all transaction types ;
> * DECLINED: sale, preauth, transfer;
> * FILTERED: sale, preauth, transfer, reversal;
To apply the rates to an event you should define the following parameters:
 
> * Minimum (min)
> * Percentage (rate)
> * Fixed (absolute) rate (abs)
> * Hold percentage (hold)
> * Hold period
> * User defined function
The rate is calculated in the following way:
 
> * the maximum of the defined minimum and percentage multiplied by the transaction amount is first calculated: greatest (min, amount\*rate)
> * to the calculated value the fixed rate is added: greatest (min, amount\*rate) + abs
> * the hold is being withdrawn: greatest (min, amount\*rate) + abs + hold
> * the User defined function gets applied. The function can redefine the calculation
> * the transaction amount is deducted by the calculated amount
When you define rates for the BIN, bank or country you should set the following parameters:
 
> * Minimum (min)
> * Percentage (rate)
> * Fixed (absolute) rate (abs)
> * User defined function
You are not allowed to redefine the hold parameters. For the redefined events the following priority search will be applied: first the BIN redefined rate is being found, if it’s not found, the system looks for bank redefined rate, if it’s not found the country redefined rate is being searched. If none are redefined the default rate in applied.
 

#### Rates table configuration

To get the better flexibility to define the rates you can use rate table definition user interface.
 
For the types of transactions that initiate the orders, except for the transfer, the single level range rates table is supported. The range can be defined for: transaction amount, total amount and total number of the transactions processed by the Gate for the current month.
 
For the transactions that do not initiate orders you can define the following ranges: the ratio of the current number of transactions of this type to the total number of the transactions for the current or past month.
 
For transfer transactions you can define two levels of ranges in the rates table. The first level ranges are the same as for the transaction that initiate orders. The second level is the transfer direction. The transfer directions are defined at the Payneteasy instance level. The standard directions are: from Visa card to any other card, from Master Card card to any other card, the transfer within the bank and a lot of others. To select the desired directions, please, create an enhancement request.
 

`exclamation`

The calculation of the aggregated amounts (total amount, total number and ratio) is accomplished by default at the Gate level. In order to insure the rates transparency you should select the calculation of the aggregated amounts at the Endpoint or Project level.

Let’s examine the rates table configuration for the transfer transactions
 
Let’s assume that the Gate supports transfers for various types of cards. The rate of the transfer depends on the total amount of the transactions processed by the Gate. The limit is set to 10 000 000. You can define different rates depending on the transfer direction. If the total amount is less than 10 000 000 the rates for the following directions are applied:Visa2Any, Master Card2Any, Any2Any, otherwise the common rate is set. In this case we have the following hierarchy:
 

Let’s examine the flow of a transaction made with the card 4444 5555 6666 1111. Since the first level ranges are defined for the total transactions amount first the total amount of the transactions processed by the Gate is examined at the time of transaction processing. Assume that the total amount is 5 000 000, that means the flow goes via the upper branch. Next, the rage for the card type is defined, the card being processed is Visa. For Visa cards there’s a transfer direction Visa2Any. It means the system will pick the rate in the table: < 10 000 000, Visa2Any.
 

`exclamation`

It might happen the the card will fall into several directions at the same time. In this case the direction is selected in the following priority: the transfer within a bank, then the direction where both sender and receiver are defined (e.g. Visa2Visa), then the direction where only the sender is defined (e.g. Visa2Any), the direction where only the receiver is defined (e.g. Any2Visa), default direction.

You are allowed to define the ranges for directions as the first level of hierarchy. In this case when you define the rates table, the amount and number of the transactions will be calculated for all directions separately.
 

#### Complex rates

To define the rate plan correctly you have to understand how you can make it for different participants of the payment flow. Let’s first examine simple cases. Let’s say the commission of the participants A and B is defined solely by the minimal value and doesn’t depend on transaction amount. The participant A expects the earnings ya, the participant B – yb. In such a case you have to define the rate plan with the minimal rate of ya+yb.
 

The same logic is applied for the rates with defined percentage rate only. Let’s assume the commission of the participants A and B is only defined as a percentage of the transaction amount. The participant A expects the commission Ra, the participant B – Rb. In such a case you have to define the rate plan with the commission set to Ra+Rb.
 

Let’s examine a more complex case. Assume that both participants expect the commission as a minimal value for transactions less than certain amount and the percentage of the transaction otherwise. The threshold to switch from the minimal rate to percentage rate for the participant A is x1, for the participant B – x2. If this threshold is the same for both participants (x1 = x2), then the applied rate will be the sum of the minimal rates below the threshold and the sum of the percentage amounts above it.
 

If the parameters are different the rate is calculated in a more complex way. Let’s visualize the possible cases.
 

On the figure the minimal possible rate is marked green. In the range (x1, x2) the rate is defined by another formula than just the sum of two minimal rates and the sum of the percentage rates. It’s not possible to correctly define such a rate in a precise manner. You have to add the two ranges: x1, x2. In (0, x2] the rate is defined as a sum of minimal commissions. In [x1, x2] the rate is defined as a percentage rate of the participant A (or the participant B if his threshold triggers first) and the absolute value of the participant B’s commission which is equal to the minimal commission of the participant B (or A vise versa). In [x2, +∞) the rate is defined as the sum of the percentage rates of the both participants.
 
In order to avoid too complex rates tables you have to adjust the minimal rate value as well as the percentage. If you increase the minimal rate in the range Δmin you have to increase the percentage rate ΔR as well. If you adjust the minimal rate value by more than Δmin amount you should not adjust the percentage rates. The adjustment bounds are marked with dotted line.
 
If you ignore these adjustments for the transactions amounts that fall into (x1, x2), the commission for the participant B will be lowered (assume that B is lower in the payment flow hierarchy).

### Buffer Online Balance Holds

Shows all transactions with hold amount. For example while making payout, firstly, amount for payout is getting in buffer on hold (so in case of success, this amount would be transferred to customer account) after the transaction passed amount is released (deducted) from account. In order to hide/show the ignored holds, press ‘’eye’’ icon.

`hold`
 
It is possible to select Merchant and currency.
 
Press Export button to export file with all information regarding holds.
 
In order to turn off all reconciliation notifications of specific hold balance, press `unmute` button.

### Buffer Online Balance Releases

Shows all released amount from hold in the buffer, which will subsequently be deducted from the balance.

`release`
 
It is possible to select Merchant and currency.
 
Press Export button to export file with all information regarding holds.
 
In order to turn off all reconciliation notifications of specific hold balance, press `unmute` button.

### Buffer Online Balance Topups

Shows all top ups in the buffer, which will subsequently be added to the balance (e.g. sale).

`top-up`
 
It is possible to select Merchant and currency.
 
Press Export button to export file with all information regarding top-ups.
 
In order to turn off all reconciliation notifications of specific balance top-up, press `unmute` button.

### Buy Now Button

Buy Now Button integration is relevant for Merchants who has limited portfolio of products to sell. It is the easiest way to integrate with Payneteasy. This way of integration doesn’t require much technical effort. Buy Now Button integration also allows Merchant (or Connecting Party which represents Merchant) to exclude itself from storing, processing, or transmitting Payer’s cardholder data or other sensitive payment details. Such data is submitted by Payer on Payneteasy hosted customer details form and payment form in PCI DSS certified environment.

#### Buy Now Button Setup

To configure Buy Now Button for Merchant’s website follow these instructions:

> • Find the relevant Endpoint
> • Go to Buy Now Items tab
> • Click Add item
> • Fill in the required fields.

#### Buy Now Button Required Fields

| Parameter Name | Description | Value |
|------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------|
| Amount | Amount to be charged. The amount has to be specified in the highest units with . delimiter. For instance, 10.5 for USD means 10 US Dollars and 50 Cents. | `Necessity`: Required `Type`: Numeric `Length`: 10 |
| Description | The item’s description. | `Necessity`: Required `Type`: String `Length`: 64k |
| redirect_url | The URL to the page where the Payer will be redirected after transaction is completed. | `Necessity`: Required `Type`: String `Length`: 1024 |
| Destination | Destination to where the payment goes. It is useful for Merchants who let their payers to top up their accounts with bank card (Mobile phone accounts, game accounts etc.). Sample values are: +9999999999; mail@example.com etc. This value can be used by the fraud monitoring system. | `Necessity`: Optional `Type`: String `Length`: 128 |
| Payment tool | Payment methods. | `Necessity`: Optional `Type`: String `Length`: 128 |

#### Buy Now Button Payment Form Fields

> To configure the fields to be shown on payment form, ask Payneteasy support manager to:
> • Go to API fields on the proper Endpoint.
> • Mark each needed API field as Visible and/or Required.
> • Save API fields and preview the payment form.

> **Warning:** It is strictly advised to create separated Endpoints for Buy Now Button because activating this option might lead to errors with other types of integration. Also:

1. Buttons cannot be removed, only entire Endpoint can be disabled to stop transactions via Buy Now Button.
 
2. Transaction amount change on payment form will not be supported if any Buy Now Button is configured on this Endpoint.

### Cashflow Report

Calculates transaction turnover: sale, chargeback and amount of funds held. Shows the distribution of turnover, taking into account commissions and approximate profit for the period, as well as broken down by days.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use:
 
 

 
Data is uploaded by pressing the Generate button. An example of the table obtained during unloading is shown in the figure below:

### Chain Strategy Details

Chain strategy details allows to select which Declines (negative processing results) will continue or stop the chain.

If the configured routing has such balancing types as: Chain by Sequence, Chain by Equivalently on Tx Count, Chain by Coefficient on Tx Count, it’s possible to go to the “Chain
Strategy Details” tab on the gate level and select the criteria to continue or stop the chain.

The number and name of the gate is at the top of the page.
The active line “Continue the chain” is located below and the choice of criteria is to the right of it.
“Independently of the decline reason” is selected by default.

Two active columns – “Unavailable” and “Available” – are located below.
The reasons for decline are located in the “Unavailable” field.
The chain can continue:

> - Independently of the decline reason - the chain will continue regardless of the received decline codes.
> - Only for the selected decline reasons - the chain will continue only for the specified decline reasons. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button.
> Confirm the parameters with the “Save” button.
> - For any decline reason except the selected ones - the chain will continue for all reasons, EXCEPT for the specified ones. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button.
> Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.

### Chain Strategy Skips

Chain strategy skips allows to skip a gate per PAN for a transaction if one of selected errors codes occur. After transaction is declined for a specific PAN on one gate, this gate will be skipped from cascading on next transactions with the same PAN for the specified time period (set in minutes).

> `chainstrat balancing 2.0`
 
This functionality is supported for the following options:
 
- Chain by Sequence
- Chain by Last Customer tx Status on Acquirer
- Chain by Coefficient Based on tx Count
- Chain by Equivalent Coefficient Based on tx Count
- First in Sequence
- First in Sequence by Last Customer tx Status on Acquirer
- First in Sequence by Last Customer tx Status on Gate

### Chargeback flow and transaction types

#### Chargeback terms

| Name | Description |
|----------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Retrieval Request | An Issuer\`s request for a Transaction Receipt, which could include the original, a paper copy of facsimile, or an electronic version thereof |
| Chargeback | A Transaction that an Issuer returns to an Acquirer. The Issuer can only make chargeback for a valid reason as described in VISA/MC rules |
| Representment | * an Acquirer rejects or responds to the chargeback made by the Issuer and * sends the transaction back to the Issuer and * supports it with additional documentation that remedies the disagreement The Acquirer can only make representment for a valid reason as described in VISA/MC rules As this is the 2nd time that Acquirer presented this transaction to the Issuer, it is called representment |
| Arbitration Chargeback | A Transaction that an Issuer returns to an Acquirer for the 2nd time. The Issuer can only make chargeback for a valid reason as described in MC rules |
| Prearbitration | An attempt to resolve the dispute before filing with VISA/MC Arbitration Committee |
| Arbitration | A process whereby financial liability for Transactions processed through Interchange that are presented and charged back is determined by VISA/MC |
| CPD (Central Processing Date) | A date when a record (transaction, chargeback, retrieval request etc) has been processed by international payment card schemes |
| Compliance | A process whereby disputes that arise from violations of any rules governing a Transaction, and no Chargeback right is available, are determined |
| Good Faith Letter | An attempt to resolve the dispute when no chargeback of compliance rights exist |
| SAFE/Fraud Advice TC40 | A record prepared by an Issuer to inform VISA/MC of fraudulent merchant activity |
| TID (Transaction information document) | Term used for transaction documentation, such as form sets, records, sales slips, terminal receipts, and record of charges |

#### Master Card Chargeback Guide

##### Chargeback Flow

```plantuml
participant MasterCard
participant Acquirer
participant Issuer

activate Issuer
"Acquirer" -> "Issuer": First Presentment - 7 days

 "Acquirer" //-- "Issuer": Retrieval request
 activate Acquirer

 "Acquirer" --> "Issuer": Retrieval request fulfilment

 deactivate Acquirer

 "Issuer" -> "Acquirer": Сhargeback
 deactivate Issuer

 activate Acquirer

 "Acquirer" -> "Issuer": Second Presentment

 deactivate Acquirer
 activate Issuer

 "Issuer" -> "Acquirer": Arbitration Chargeback
 deactivate Issuer
 activate Acquirer
 Acquirer -> MasterCard: ARBITRATION
 deactivate Acquirer
```

##### Chargeback Stages

| Timeframe | Stage | Description | MIT-Function Code (s) | API Method | Overall window |
|-------------|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------|---------------------|--------------------|
| | First Presentment | Acquirer submits the transaction to the issuer | 1240-200 | sale | 45/60/120/540 days |
| 30 days | Retrieval Request | Issuer may request a copy of the sales ticket to support or identify a potential chargeback. NOTE: Most chargebacks do not require a retrieval request | 1644-603 | retrieval | 45/60/120/540 days |
| 30 days | Retrieval request fulfilment | | | | 45/60/120/540 days |
| 45 days | Chargeback | Issuer initiates a chargeback within the time frame applicable to the specific message reason (Refer to section 3, Master Card Message Reason Codes—Dual Message System Transactions for details). NOTE: If an issuer receives a legible copy of the TID through a second presentment for message reason code 4802—Requested/Required Information Illegible or Missing, and after viewing the item for the first time determines that it has another right of chargeback for a different message reason code, the issuer must start the process again with a new chargeback. Refer to section Message Reason Code 4802—Requested/Required Information Illegible or Missing for more information | 1442-450 (full amount); 1442-453 (partial amount) | chargeback | 45/60/120/540 days |
| 45 days | Second Presentment | When applicable, the acquirer may process a second presentment within 45 calendar days of the Central Site Business Date (PDS 0158 [Business Activity], subfield 5 [Business Date]) of the chargeback | 1240-205 (full amount); 1240-282 (partial amount) | chargeback_reversal | 45 days |
| 45 days | Arbitration Chargeback | When applicable, the issuer may initiate an arbitration chargeback within 45 calendar days of the Central Site Business Date of the second presentment | 1442-451 (full amount); 1442-454 (partial amount) | prearbitration | 45 days |
| 45 days | Arbitration Case Filing | The acquirer may file an arbitration case to Master Card for a decision on the dispute within 45 calendar days of the Central Site Business Date of the arbitration chargeback | N/A | arbitration | |

#### Visa Chargeback Guide

##### Chargeback Flow

```plantuml
participant Acquirer
participant Issuer
participant VISA

activate Issuer
"Acquirer" -> "Issuer": First Presentment - 6 days

 "Acquirer" //-- "Issuer": Retrieval request
 activate Acquirer

 "Acquirer" --> "Issuer": Retrieval request fulfilment

 deactivate Acquirer

 "Issuer" -> "Acquirer": Сhargeback
 deactivate Issuer
 activate Acquirer

  "Acquirer" -> "Issuer": Representment

 deactivate Acquirer
 activate Issuer

  "Acquirer" //-- "Issuer": Prearbitration attempt

 activate Acquirer

 "Acquirer" --> "Issuer": Prearbitration response

  deactivate Acquirer
  Issuer -> VISA:    ARBITRATION
  deactivate Issuer
```

##### Chargeback Stages

| Timeframe | Stage | Description | API Method | Window | Overall window |
|-------------|--------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------|----------|------------------|
| | First Presentment | Acquirer submits the transaction to the issuer | sale | | |
| 30 days | Retrieval Request | Issuer may request a copy of the sales ticket to support or identify a potential chargeback | retrieval | | 75/120/540 days |
| 30 days | Retrieval Request Fulfil | | | | 75/120/540 days |
| 45 days | Chargeback | Issuer initiates a chargeback within the time frame applicable to the specific message reason | chargeback | | 75/120/540 days |
| 45 days | Representment | When applicable, the acquirer may process a second presentment | chargeback_reversal | 29 days | 60(30\*) days |
| 30 days | Prearbitration Attempt | Before filing for Arbitration, the requesting Member must make a pre-Arbitration attempt using Visa Resolve Online, at least a full 30 calendar days prior to the Arbitration filing date if any of the following conditions apply: * New documentation or information is being provided to the opposing Member about the dispute * The Acquirer represented with Compelling Evidence. The Issuer must certify in its pre-Arbitration attempt that it attempted to contact the Cardholder to review the Compelling Evidence. * The Issuer changes the reason code for the dispute after the Representment was processed * The Acquirer provided evidence that the Cardholder no longer disputes the Transaction. The Issuer must certify in its pre-Arbitration attempt that the Cardholder still disputes the Transaction | prearbitration | 29 days | 60(30\*) days |
| | Prearbitration Response | | | 30 days | 60(30\*) days |
| | Arbitration | If the opposing Member does not accept financial responsibility for the disputed Transaction, the requesting Member may pursue Arbitration | arbitration | 30 days | 60(30\*) days |
| | Arbitration Appeal | The decision on any permitted appeal is final and not subject to any challenge | | 30 days | 60(30\*) days |

\* 30 days apply if no prearbitration attempt

#### Visa Compliance Guide

##### Chargeback Stages

| Stage | Description | API Method |
|----------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------|
| First Presentment | Acquirer submits the transaction to the issuer | sale |
| Cardholder or issuer disputes the first presentment | | |
| Pre-Compliance | Before filing for Compliance, the requesting Member must attempt to resolve the dispute with the opposing Member. This attempt must include all of the following: * Attempt date * Clear identification as pre-Compliance attempt * Planned Compliance filing date * All pertinent documentation * Specific violation of the Visa International Operating Regulations A pre-Compliance attempt must include the information required in the Pre-Compliance Attempt Questionnaire. The pre-Compliance attempt must be sent electronically, using Visa Resolve Online, at least a full 30 calendar days prior to the Compliance filing date | |
| Pre-Compliance Acceptance | If the opposing Member accepts financial liability for the disputed Transaction, it must credit the requesting Member for the last amount received by the requesting Member through Visa Net within 30 calendar days of the pre-Compliance attempt date | |
| Non-Acceptance of Financial Liability for Pre-Compliance | If the opposing Member does not accept financial liability for the disputed Transaction, the requesting Member may pursue Compliance | |

### Close Day Report

Displays the exact time when the close day procedure for settlement was performed on each gate.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Close day

#### Overview

For some processors, funds are transferred to the bank account only after the Close Day procedure, which initiates bank clearing.

Close Day procedure can be initiated via API, manually with “Close Day” button on the Gate level, or automatically each day at pre-set or system selected time. If for any reason it is not possible to make “Close Day” using via API, then it is necessary to perform “Close Day” procedure manually on the Gate level.

> **Warning:** During the Close Day procedure the following gate will be blocked and transactions will not go through it.

#### Manual day closure

 
In order to perform Close Day procedure, go to Settings -> Configuration -> Gates:
 
 

 

 
On the gate details page, click the Close day button and confirm this action on the pop-up window. The window “Close day for ‘gate name’” will appear on the page. Wait for the operation to complete:
 
 

 
After the successful day closure, the gate details page will display the day closing date and the amount of transactions from the last to the current day closing date:
 
 
`lastday`

#### Automatic day closure

 
In order to perform Close Day automatically, go to Settings -> Configuration -> Gates:
 
 

 

 
On the gate details page, click the Edit button, mark Automatic closing of the day and click Save. The optimal Close Day time is selected by the system automatically (UTC+3):
 
 
`autoclosure`
 
After each successful day closure, the gate details page will display the day closing date and the amount of transactions from the last to the current day closing date:
 
 
`lastday`

#### Automatic scheduled day closure

 
In order to perform Close Day automatically at pre-set time, go to Settings -> Configuration -> Gates:
 
 

 
On the gate details page, click the Edit button and mark Close day automatically. After that Close day time row. Select the preferred close day time and then click Save. Please note, that Automatic closing of the day checkbox must be turned off, otherwise the gate closing time will be selected automatically by the system:
 
 
`autoclosepreset`
 
After each successful day closure, the gate details page will display the day closing date and the amount of transactions from the last to the current day closing date:
 
 
`lastdaytime`

#### Allow closing day via API

In order to allow this procedure via API, go to Settings -> Configuration -> Gates:
 

On the gate details page, click the Edit button, mark Allow closing day via API. The number of days after which the Close Day will be triggered automatically can be set in the Day closing maximum delay (days) (3 days is automatically set) then click Save:
 
`closeday_via_api`

#### Gate Lock Release Tool

If during the gate closure via API one or more Gates remained blocked (in the body of the response with status: finished for Gate - is Day Closing : true), then removal of the lock can be done manually. In order to make this procedure go to Settings -> Configuration -> Gates:

 

 
On the Gate details page tap on Locks:
 
 
`gatelock`
The current Gate lock information is displayed in the “Current locks” menu:
 
* Lock session ID - ID of the lock session.
* Start day closing date - the start date of the Close Day.
* Bank terminal lock status- blocking the Endpoint for performing transactions (Blocked/Free).
* Initial gate job status - the status of the initialization Gate.
* Close day job status - the status of the closing Gate.
* Is day closing - the Gate is in the closing stage which means that is it locked or not (Y/N). Y - the Gate is blocked, N - not blocked.

The following unlock commands are available:

* CLEAR_TRANSACTION_LOCK - reset the session that caused the lock.
* CLEAR_INIT_ATTEMPT- reset the status of the initialization Gate.
* CLEAR_CLOSING_DAY_ATTEMPTS - reset the status of the closing Gate.
* CLEAR_CLOSING_DAY_FLAG - reset the assignment of the closing Gate, remove the lock.

Mark the applicable menu checkbox and click the Update button.

After the unlock, re-open the Gate Lock Release Tool and check that the status of the lock parameter has changed in the “Current locks” menu. For example, if the Gate was blocked, then after removing the lock, the parameter equals to Is day closing = N.

`closedaylock`

### Configuration

### Customers Management

#### Introduction

Customer Management - is a module which allows to set custom payment flow. It is located at Settings -> Customers management.
This screen contains the list of all Merchants in the system tat are connected to Customers Management.

 

 

On this screen it is possible to make a search by Merchants or to add new Merchant (Configuration) into the Customer Management module by pressing Add new button on the right top corner of the screen.

#### Adding New Merchant To Customer Management

After pressing Add new button, this screen will popup:

 

 

First select the Merchant in Merchant field which will be connected to Customer Management system.

 

Then select one of the operation mode - CRM (API) or Payment Gateway.

- CRM (API) - allows to determine Customer by merchant customer id. Not configured levels are created if customer level parameter is present in API calls.
- Payment Gateway - allows to determine Customer by internal customer id.

 

> **Warning:** Please note that for proper operation, the parameter must match the Client Definition value set on the endpoint or project

In default behavior select either Project or Unknown Level.

- Project - In case if not configured customer level is present in API calls, Project and Endpoint settings (Client definition) will be used.
- Unknown Level - In case if not configured customer level is present in API calls, Unknown level settings will be used.

 

> **Warning:** Any misconfiguration may lead to payment processing stop.

After selecting Operation mode and Default behaviour, (by choice) select one of the choices or both:

- Reset individual payment settings when customer level changed.
- Automatically add all merchant projects to Unknown level
- Reset show in from when changing customer level.

 

After adding Merchant to Customer Management it is possible to edit or delete configuration.

##### CRM

> CRM (API) - allows to determine Customer by merchant customer id.
Parameters used in CRM configuration:
 
- merchant_customer_identifier
- customer_level

> **Warning:** customer_id should not be included in the request.

```plantuml
  title CRM operation mode
  start
  :(1) Receiving [merchant_customer_identifier] and [customer_level] from Connecting Party;
  if (
  (2) System will check if such user was already registered in Customer Management.

  Does customer with such [merchant_customer_identifier] already exist?
  ) then (Yes)
    :(3) Customer was already registered in
  Customer Management.

  Customer is being identified by
  merchant_customer_identifier;
    :(4) Routing will be chosen according to the
  level sent in the request.

  Customer level in the system will be set equal to
  customer_level in request.;
  else (No)
    :(5) Registering new customer in Customer Management
  with id passed in merchant_customer_identifier.

  New Customer is being identified by
  merchant_customer_identifier;
    :(6) Routing will be chosen according to the
  level sent in the request.

  Customer level in the system will be set equal to
  customer_level in request.;
  endif
    :(7) Routing being adjusted according to level specifications.;
  stop
```

(3), (5) merchant_customer_identifier should not be passed with empty value. If merchant_customer_identifier is sent with an empty value, the customer will be created in Customer Management and can only be identified using the Client Definition configured at the Project or Endpoint level.
 
(4), (6) In case of customer_level being sent empty, customer will be granted an empty level or Unknown level, if Unknown level Default Behaviour was configured.
 

> **Warning:** Parameters being sent improperly could lead to transactions being incorrectly routed or not being processed entirely.

##### Payment Gateway

> PNE (GATE) - allows to determine Customer by internal customer id.
Parameters used in PNE configuration:
 
- customer_id
- customer_level

> **Warning:** merchant_customer_identifier should not be included in the request.

```plantuml
  title PNE (GATE) operation mode
  start
  :(1) Receiving [customer_id] and [customer_level] from Connecting Party.;

  if (
  (2) System will check if such user was already registered in Customer Management.

  Does customer with such [customer_id] exist?
  ) then (yes)
    :(3)  Customer was already registered in
  Customer Management.

  Customer is being identified by customer_id;
    :(4) Routing is chosen according to the
  level of customer in Customer Management.

  Customer level in the system will be set equal to
  customer_level in request.;
  else (No)
    :(5) In case of customer with customer_id value sent in the request
  have not been found in Customer Management, routing rules
  won't be applied.;

  endif
    :(7) Routing being adjusted according to level specifications;
  stop
```

(3), (5) In case of customer_id being sent empty, Client Definition set on Project or Endpoint level being checked and if no customer found, new customer with new customer_id will be created.
 
(4), (6) In case of customer_level being sent empty, routing will be set according to Unknown level or Project default behavior that was configured.
 

> **Warning:** Parameters being sent improperly could lead to transactions being incorrectly routed or not being processed entirely.

If Auto leveling is enabled for the Merchant, Customer level can also change automatically based on accumulated transaction history, independently of this request flow — see [Auto Leveling](#auto-leveling).

#### Level Configuration

Level configuration can be done for Deposits and Withdrawals. In order to add configurations press +Add button and select the name, currency and projects.

 

 

> **Note:** The currency may vary based on the currencies in which the Merchant’s Projects are available.

 

 

unknown is a default level that will be created automatically.

 

On the screen shown above, all levels will be displayed with the next information:

- Level name
- Currency - supported currencies on the level
- Projects - all Merchant’s projects that are connected to Customer Management.
- Created and Modified - which will show the time - configuration was created or modified.

 

Configuration for a specific currency can be toggled on/off or whole configuration can be deleted.
Press edit button to add/remove projects from level.

##### Customer level configuration

Press on Level Name to access Customer level configuration. In opened window select Level configuration to setup custom payment flow for Customer level or Filters to add additional checks for level.

 

This screen will display information about level such as - Payment direction - Deposit or Withdrawal, Currency, Level name, Status - which shows the status of level (active/disabled).

 

 

In Payment methods section all available methods for Payment Cashier will be displayed. By pressing on any of the methods Configuration window will popup.

In Configuration section press Reset to default to restore all setup to default;
 
Check or uncheck the Show in form box to show/hide selected payment method from the Payment Cashier Form;
 
Set min/max amount which will set or override these parameters on Endpoint level.
 
Press Save button for the configuration to be applied.
 
 
In Gate list select which Routing route or gate will be available for selected level.
 
 
After all configurations - changed payment methods will be moved to Edited tab. All unchanged methods will be shown in Default tab.
 

##### Auto leveling

Auto leveling allows Customer level to be changed automatically, based on configured rules, without manual intervention from Manager.

> **Note:** Auto leveling is only available when Customer Management is configured in Payment Gateway (PNE) operation mode. Transactions are being counted only for card/email Client Definition configurations on Endpoint/Project.

Rules are configured separately for Deposit and Withdrawal payment directions.

 

 
- Collect Data from - selects the entity whose transaction history is used to calculate the rule: Merchant or Manager.
- Type of calculation - selects which transaction metric triggers the level change: Count, Amount, Count and Amount or Count or Amount.

> **Note:** Currency selection is only available for Amount, Count and Amount and Count or Amount types of calculation.

 

 

For each level added to the rule, Level name should be selected, together with the threshold value (s) required for Customer to reach that level, depending on the selected Type of calculation.

 

> **Warning:** Customer level is changed by only one level at a time, even if the transaction count/amount would be enough to cover several levels in the line. Transactions are counted within a rolling 180-day window from the last level change, and any amount exceeding the current level’s threshold is carried over towards the next level for the remainder of that window. Auto leveling does not automatically downgrade a Customer level.

 

New Customers tracked under an Auto leveling rule are assigned the first level of the rule’s line, rather than the unknown level, since unknown remains a technical level for projects not connected to a rule.

> **Note:** This behaviour applies only to Customers created under an Auto leveling rule and does not change the Default behaviour (Project / Unknown Level) configured for the Merchant.

##### Filters

Transaction filters in System are intended for rejection of certain transactions on various reasons.

 

 

There are three level filters:

- Сustomer id usage frequency for last 24 hours (daily limit)
- Сustomer id usage frequency for last 7 days (weekly limit)
- Сustomer id usage frequency for last month (monthly limit)

 

| Name | Description | Value |
|------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------|
| amount limit | maximum total transactions amount for the last 24 hours (week, month) for exact Customer id | 99999 |
| calendar week starts from Sunday | “Yes”: calendar week starts from Sunday, “No”: calendar week starts from Monday | Yes/No |
| for all merchant currencies in CMS | current total transactions amount or count for the last 24 hours (week, month) for this customer id would be calculated “Yes”: for all merchant levels in all currencies in payment direction (Deposit or Withdrawal) and converted to the currency of the current level for comparison with the amount limit “No”: for current level only | |
| quantity limit | maximum total transactions count for the last 24 hours (week, month) for exact Customer id | 99999 |
| subtract Cancel transactions | | |
| use calendar day | | |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 19000 | | Daily amount limit exceeded for customer id |
| 19001 | | Daily quantity limit exceeded for customer id |
| 19002 | | Weekly amount limit exceeded for customer id |
| 19003 | | Weekly quantity limit exceeded for customer id |
| 19004 | | Monthly amount limit exceeded for customer id |
| 19005 | | Monthly quantity limit exceeded for customer id |

#### Customers

Individual configuration can be done for Customers. Depending on the parameter that were sent (customer_id, customer_level, merchant_customer_identifier), customer can be created automatically or manually through Customers screen. Press on Customers in order to access the Customers screen.

All customers with brief information will be displayed on this screen.
 

 

As shown on the image above, press 1 - Show filter to open additional criterion for search. In popp up screen select next criterion: (Payment Gateway’s) Customer IDs, Merchant Customer IDs, Deposit level name, Withdrawal level name, Email or Date range (creation dates).

It is possible to add,change or delete information from the 2 bar or through filter section.
 
 

Select group of customers or all of them to Set global limit or Change level - for all selected customers.

Press Create to create new customer.
 
 

Press Download to download list of all customers with their details.
 
 
Press Upload to upload the list of the customers with their details using the options, shown below:
 

Upload CSV - for uploading the list of customers;
 
Download template - for downloading an example file;
 
gen mock - for generating customers with fake data.
 

Upload CSV - for uploading the list of existing customers with new configuration;
 
 

> **Note:** The uploaded file fully overwrites the configuration: existing data may be not only added, but also overwritten or erased. Make sure the file contains complete and correct data.

##### Common Settings

By pressing on any customer’s ID next window will pop-up:

 

 

In Common settings all customer information will be shown. Under Actions menu, press Edit info to change customer information except Customer ID and Merchant customer ID. The Virtual terminal button will allow to open the virtual terminal with al customer information directly from this screen. All orders will show all orders associated with customer.

##### Individual Payment Settings

Individual payment settings allows to setup Cashier Payment Form for each customer separately. First choose level and currency for the setup. Then select Use as global limit for customer if min/max amount for currency should be applied for all available solutions . Select Payment methods and apply setup if needed. By pressing Virtual terminal button Virtual terminal with all customer information will be opened.

### Dashboard

#### Transaction Monitor

Transaction monitor is available at the top of the page for general statistics:

 

This monitor contains the following blocks:

| `Turnover` | The sum of all successful sale, capture, reversal (refund) and transfer operations |
|-----------------------------------------------------------|--------------------------------------------------------------------------------------|
| `Declined`, `filtered and verify` | The number of operations of the aforementioned types with the corresponding status |
| `Chargebacks` | The number and amount of successful chargeback and prearbitration operations |
| `Frauds` | The number and amount of successful fraud operations |
| `Reversals` | The number and amount of successful reversal and void operations |

To view the analytics detailed by each payment method, click the pointer on the right side of the relevant block:

 

#### Analytics

##### Data Scope

To change the range of statistics, use the switches:

 

Set the desired date range in the pop-up calendar:

 

Data for graphs can be sorted using the Add filter button:

 

Currencies, payment methods, as well as endpoints, projects and other data can be specified for analysis.
Here is the example of the payment method selection to construct the chart:

##### Charts bundle

 
Ratio of successful, rejected and filtered by the system transactions are displayed in the following graph:
 
 

The following graphs can be also selected: the ratio by volume of transactions or by amount of payments, as well as by type of transactions (sale, capture, transfer, etc). Payneteasy Payment Gateway also displays statistics on negative activity and earnings.
 
Required time period is set by schedule switch (day, week, month):
 
 

 
Type of chart (amount, count, all) can be changed using the button:
 
 

##### Approval Ratio

The graph shows the proportions between successful, declined and filtered transactions for a selected period of time.
 
Payneteasy Payment Gateway also displays statistics per card payment system, per currency, as well as per payment method.
 
Successful Transaction Analytics for the specified period are displayed as follows:
 
 

##### Transactions By Country

Overview of analytics by country displays two types of regional statistics: based on customer IP addresses and on card BINs.
 
 

##### Transaction Decline Reasons

This statistics screen can be used for a visual assessment of the most frequent decline reasons, as well as chargeback and fraud reasons.

### Decline Statistics

This report allows to get statistics on rejected transactions, which are divided into the following groups: rejected by the acquiring bank, rejected by internal fraud system and rejected due to an internal error.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Preview of this report can be viewed by clicking on the Preview button.
 
The Report can be generated by clicking on the the Generate button.
 
An example of the resulting report is shown below:

### Employees

#### Create Employee Account

Creating new accounts to access the system is available in “Settings” – “Employees”.
 
The Employees tab contains a list of all employees accounts, established in the system for the all users connected to manager.
 
New employee account can be created with the Add User button. The following form must be filled:
 
 

 

Scope username should be clicked in order to open the drop-down menu and select main account of the manager or other user, which needs a new employee account:

 

 

Next, select one of available employee roles in the system:

 

After the personal account is created, an employee can immediately log in. Login and password are generated at the stage of creating a personal account (do not forget to save the password beforehand). If the password was not saved, it can be reset on employee details screen.

 

 

When employee logs in to the account for the first time, the system asks to change the temporary password to a permanent one:

 

#### User Privileges

Here are all available roles for Merchant, Reseller, Manager, Dealer and Superior.
 

##### Merchant

Main Merchant account has access only to his traffic and not able to see other Merchants.
 

| Employee type | Description |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| merchant-support | This employee is the same as Merchant account, but not able to create Merchant employees. Can reverse orders from orders page |
| merchant-support-readonly | This employee is limited version of merchant-support, no access to the configuration change. Can reverse orders from orders page |
| merchant-risk | This employee has access to transaction details and actions with them, view and operate with BWL lists and BWL options from order details page, Reports and Batch operations. Can reverse orders from orders page |
| merchant-risk-readonly | This employee has access to transaction details, view and operate with BWL lists and BWL options from order details page, has no access to Reports and Batch operations |
| merchant-finance | This employee has access to view some entities in the system, Dashboard and transaction details |
| merchant-finance-readonly | This employee can see only transaction details, Batch operations and Reports |
| merchant-vt-only | This employee has access only to Virtual terminal |
| merchant-vt-transaction | This employee has access only to Virtual terminal and transaction details |
| merchant-desc | This employee can see only Dashboard and transaction details |
| merchant-loyalty | This employee can see only BWL lists and transaction details |
| merchant-client-support | This employee can see only transaction details |
| merchant-transaction | This employee is almost identical to merchant-client-support |
| merchant-analyst | This employee is almost identical to merchant-transaction with access to Dashboard, can’t view Projects |

##### Reseller

Main Reseller account has only access to see the traffic for the Projects linked to this Reseller.
 

| Employee type | Description |
|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|
| reseller-support | This employee is the same as Reseller account, but not able to create Reseller employees |
| reseller-finance | This employee is the same as reseller-support, but not able to deal with rate plans |
| reseller-no-finance | This employee is the same as reseller-support, can create employees, but no access to banking information at all |
| reseller-desc | This employee is the same as reseller-support, has access to some actions with transactions and transaction markers, but no access to Integration panel |
| reseller-client-support | This employee is the same as reseller-support, can see uploaded documents on Order details page, but no access to the Dashboard and Adjustments |

Ask the Payneteasy support manager to find the most suitable roles for specific cases or get a complete list of the roles functionality.

##### Manager

Main Manager account logically is same as Superior account, but doesn\`t have access to other Managers.
 

| Employee type | Description |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| manager-support | This employee is the same as Manager account, but not able to create Manager employees. Can reverse orders from orders page |
| manager-no-settings | Limited version of manager-support, without access to the configuration at all. Can reverse orders from orders page |
| manager-no-finance | This employee has access to the configuration, BWL lists, but without financial reports and actions that could be done with transactions |
| manager-limited-support | Extended version of manager-no-finance, because it has access to the processing limits page, to the rate plans and can work with BWL lists. Also can manage employees |
| manager-view | This employee is the same as Manager account, but not able to edit anything |
| manager-limited-view | Limited version of manager-no-settings, without access to the processors on Order details page, but with access to Gates. Can reverse orders from orders page |
| manager-finance | Limited version of manager-support, but cannot edit Merchant details and with very limited Tools page. Can reverse orders from orders page |
| manager-restricted | Limited version of manager-support, the minimum of entities |
| manager-transaction | This employee has access only to view transaction details |
| manager-transaction-readonly | Same as manager-transaction, but cannot download transaction reports from Orders page, decrypt customer data and see total turnover amount |
| manager-banking | This employee has access only to view transaction details, Dashboard and Transaction report |
| manager-report | This employee has access to view transaction details, Dashboard and Transaction report, BWL lists and Batch operations |
| manager-loyalty | This employee has access only to BWL lists (not from Order details page) |
| manager-loyalty-extended | This employee has access to view transaction details and to BWL lists |
| manager-sales | This employee has access to Dashboard, to view transaction details and all entities without Edit option |
| manager-reconciliation | This employee has no access to Batch operations, has access to Transaction reports, to view transaction details and all entities without Edit option |

##### Dealer

Main Dealer account has only access to see the traffic for Gates and Processors linked to this Dealer.
 

| Employee type | Description |
|------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| dealer-support | This employee is the same as Dealer account, but not able to create Dealer employees |
| dealer-finance | This employee is a limited version of dealer-support with very few differences |
| dealer-finance-limited | This employee is a limited version of dealer-finance without access to a customer personal info (billing address, email and phone number) and transaction reports through the orders page |
| dealer-limited | This employee is a limited version of dealer-finance without access to a customer personal info (billing address, email and phone number) and gates |

##### Superior

Main superior account is able to see and manage all Manager accounts that belong to current account, as well as all Merchant accounts that belong to the following Managers.
 

| Employee type | Description |
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| superior-support | This employee is the same as Superior account, but not able to create Superior employees. Can reverse orders from orders page |
| superior-limited-support | Limited version of superior-support, there is no access to reconciliation and balance pages, no Integration panel and Processing limits page. Can reverse orders from orders page |
| superior-client-support | This employee is able to see only transactions |
| superior-transaction | More extended type than superior-client-support, this employee is also able to download transaction report and view the details of some entities in the system (without Edit option) |
| superior-desc | More extended type than superior-transaction, this employee also has access to the Dashboard, actions which could be done with Orders, but doesn\`t have access to entities from Order details page. Can reverse orders from orders page |
| superior-finance | This employee differs from Superior role by the following: no access to the Dashboard and configuration. Can reverse orders from orders page and has access to Adjustments |
| superior-no-finance | This employee has access to the configuration, BWL lists, but without financial reports and actions that could be done with transactions |
| superior-restricted | This employee has access to the configuration, BWL lists, processing limits page, rate plans. Also can manage employees |
| superior-risk | This employee doesn\`t have access to the configuration, but has access to Dashboard, Order details and actions, Reports, Statements, BWL option. Can reverse orders from orders page |
| superior-sales | This employee has access to transactions and Virtual terminal |
| superior-view | The same as Superior account, but without Edit option |
| superior-vt-transaction | This employee has access to transactions, Virtual terminal and can view some entities |

### Endpoint

**Endpoint Overview**
 
 
Endpoint is uniquely identified terminal in Payment Gateway, which is assigned to the Merchant and has to be provided in the commands within Payment Gateway API. The Endpoint list screen is located at Settings -> Configuration -> Endpoints. This screen contains all Endpoints created for all Merchants in the system.
 
 

 
- Endpoint is enabled.
 
- Endpoint is disabled.
 
 
To monitor the Endpoint activity, Key Performance Indicators (KPI) are used, such as: Merchant earnings, Average order value, and others. The KPI submenu opens by pressing the Detailed button on the Endpoint search screen. See details in [KPIs Detailed View](https://doc.payneteasy.com/manager/reference/kpi.html.md).
 
Click on the Endpoint name to open detailed information about this endpoint.
 
It is possible to configure custom payment forms on Endpoint or Master Endpoint, see [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) in integration documentation. Customized forms can be installed on Endpoint details screen.
 
To view the filters configured on the Endpoint, use the “Fraud protection filters” tab.
 
To view the necessity of additional fields on payment form, use the “API Fields” tab.
 
To work with other configuration options, see the information below.
 

> **Note:** The Endpoint settings (such as limits, payment forms, client definition, etc) override the Project settings.

**Endpoint Settings**
 
 

| [Create, Clone, Edit Endpoint](https://doc.payneteasy.com/manager/endpoint/endpointcreate.html.md) | This screen shows how to create and edit the endpoint. |
|-------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
| [Message Templates](https://doc.payneteasy.com/manager/endpoint/endpointmessage.html.md) | This screen shows all information about message templates sent to Customers after transactions. |
| [Endpoint Details](https://doc.payneteasy.com/manager/endpoint/endpointdetails.html.md) | Endpoint details screen contains information about configured options on this Endpoint, its ID, limits and linked Project. |
| [Callbacks](https://doc.payneteasy.com/manager/endpoint/endpointcallbacks.html.md) | This screen shows how to set up callbacks on Endpoint level. |
| [Buy Now Button](https://doc.payneteasy.com/manager/endpoint/buynow.html.md) | This screen shows information and how to set up Buy Now Button. |
| [Endpoint Account Balance](https://doc.payneteasy.com/manager/endpoint/endpointbalance.html.md) | Thi screen shows all information about Account Balances. |

### Account Balance

Each Connecting Party has a merchant user account created in Payment Gateway. If balance display is enabled, Merchant accounts can check current balances via Common tab on Endpoints. Balances also can be requested via API [by Endpoint](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance.html.md) or [by Merchant](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_merchant.html.md).
Manager can get balance of any merchant by balance name via API request - [balance by Manager](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_manager.html.md)
To configure balances, see [Account balances](https://doc.payneteasy.com/manager/users/merchant.html.md).

> **Note:** Please contact Payneteasy support to enable this feature.

An example of endpoint window with current balances is provided below:

`balancesendpoint`

### Callbacks

Additional Callback can be configured at the Endpoint level by using Create Callback utility. To set up new callback, go to the bottom of Endpoint details screen and click the “Add Callback” button. There are several parameters, which can be defined in the configuration window:

* Transaction type.
* URL address - is the fully defined URL with all the parameters Merchant’s target page or script would require. Example: [https://www.merchant.com/sale_completed](https://www.merchant.com/sale_completed).
* Comment if it is required.

### Create, Clone, Edit Endpoint

#### Endpoint Creation

 
To create endpoint, go to Settings -> Configuration -> Endpoints and press + Endpoint in the top right corner.
 
See [Endpoint details](https://doc.payneteasy.com/manager/endpointdetails.html.md) table to correctly specify the configuration for new endpoint.
 
The endpoint inherits its currency from the project it’s linked to.
 

#### Endpoint Editing And Cloning

 
Press Edit button to edit endpoint and Clone button to clone endpoint.
 
 

 

The required parameters for new endpoint are its name, the merchant to whom this endpoint will be linked, and project to which this endpoint will be linked. Endpoint currency will be inherited from linked project.
 
Other endpoint settings will be inherited automatically. In order to reset parameters to default, select Reset to default.
 
In order to see which changes for this endpoint will be cloned, press changes button.
 
 

Endpoint will show only filters which are enabled on project level, see [Transaction Filters](https://doc.payneteasy.com/manager/project/fraudprotectionfilters.html.md)
 
Endpoint filters settings rewrite project filter settings.
 
To clone filters click Clone filters.

### Endpoint Details

> **Note:** Settings specified on Endpoint level override Project level settings.

| Parameter Name | Description | Necessity for creation |
|-------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| Status | Shows whether Endpoint is enabled or disabled. Can be changed later. | Required |
| Project | Shows to which exact project this endpoint is linked. CANNOT be changed later. | Required |
| Merchant | Shows to which exact merchant this endpoint is linked. CANNOT be changed later. | Required |
| Description | Shows Endpoint description. Can be changed later. | Optional |
| Manager rate plan | Allows to set manager rate plan. Can be changed later. | Optional |
| Reseller rate plan | Allows to set reseller rate plan if reseller is selected. Can be changed later. | Optional |
| Merchant rate plan | Allows to set additional merchant rate plan. Can be changed later. | Optional |
| Payment form template | Allows to add payment form which will be displayed after initiating the transaction. | Optional |
| Wait form template | Allows to add wait form which will be displayed until transaction reaches the final status. | Optional |
| Finish form template | Allows to add finish form which will be displayed after transaction reaches the final status. | Optional |
| Tags | Shows the tag of the Endpoint. While searching Endpoints by tag, all Endpoint with the same tag will be shown. Can be changed later. | Optional |
| Loyalty service | Shows which external loyalty service is selected. Can be changed later. | Optional |
| Min transaction amount | Possible to set any minimal amount which be passed through the endpoint. Transaction requests with amounts lower than minimum will be rejected. Can be changed later. | Optional |
| Max transaction amount | Possible to set any maximum amount which be passed through the endpoint. Transaction requests with amounts higher than maximum will be rejected. Can be changed later. | Optional |
| Enable auto capture | Enables automatic capture. | Optional |
| Auto capture period (hours) | Sets the time in hours, after which preauthorized amount will be automatically captured. | Optional |
| Enable auto return | Enables automatic return. | Optional |
| Auto return period (minutes) | Sets the time in minutes, after which transaction will be refunded. | Optional |
| Message server | Allows to select message server. | Optional |
| Returning customer approve sessions count | Shows after how many transactions with final status approved, customer will be considered as returning for the endpoint. | Optional |
| Client definition | Shows by which criteria customer will be counted as new or returning for the endpoint. | Optional |
| Merchant Transfer Inquiry URL | URL of Connecting Party server for Check Transfer stage. Mandatory for [Mobile Device Transfer](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_transfer.html.md). | Optional |
| Merchant Transfer Notif. URL | URL of Connecting Party server for Transfer Card Mapping stage. Mandatory for [Mobile Device Transfer](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_transfer.html.md). | Optional |
| Merchant Sale Inquiry URL | URL of Connecting Party server for Check Sale stage. Mandatory for [Mobile Device Sale](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_sale.html.md). | Optional |
| Merchant Sale Notif. URL | URL of Connecting Party server for Sale Card Mapping stage. Mandatory for [Mobile Device Sale](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_sale.html.md). | Optional |
| Merchant Verification Inquiry URL | URL of Connecting Party server for Check Verification stage. Mandatory for [Mobile Device Verification](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_card_verification.html.md). | Optional |
| Merchant Ver. Notif. URL | URL of Connecting Party server for Verification Card Mapping stage. Mandatory for [Mobile Device Verification](https://doc.payneteasy.com/integration/api_use_cases/mobile_device_card_verification.html.md). | Optional |

### Message Templates

Message templates can be used to send SMS or E-mail messages to customer after each successful transaction. Merchant must provide their message server credentials to Payneteasy support manager in order to send such messages from Merchant address. Templates are created using the Template button. Example of filling the form:
 
 

 
Example of a message template in the form:
 
 

 
Message sending is enabled.
 
Message sending is disabled.

### Fraud/Chargeback Ratio Report

Calculates the indicators of negative statistics on the MID accounts.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Fraud/Chargeback Reasons Report

Displays a report on the causes of chargebacks for the selected parameters.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### MC/VISA/Am Ex Fraud Regulation

#### Definitions

| Country ID | Country |
|---------------------------|----------------------------------------------------------------------------------------------|
| CTR | Master Card’s or Visa’s Chargeback-to-Transaction Ratio |
| FSDVR | Master Card’s Fraud-to-Sales Dollar Volume Ratio |
| FSR | Visa’s Fraud-to-Sales Ratio |
| GMAP | Master Card’s Global Merchant Audit Program |
| CMM | Master Card’s Chargeback-Monitored Merchant |
| ECM | Master Card’s Excessive Chargeback Merchant |
| MCMP | Visa’s Merchant Chargeback Activity Monitoring |
| HRCMP | Visa’s High Risk Chargeback Monitoring Program |
| GMCMP | Visa’s Global Merchant Chargeback Monitoring Program |
| GMFPP | Visa’s Global Merchant Fraud Performance Program |
| RMFPP | Visa’s Regional Merchant Fraud Performance Program |
| International transaction | Transactions where the card was issued in the different country then the merchant is located |
| Regional transaction | Transactions where the card was issued in the same region as the merchant is located |

#### Payneteasy Flags and EFT possible Penalties

| EFT | PNE Flag | Conditions | Penalties |
|------------|--------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Master Card | CMM | * CTR 1.00% * Chargebacks Count 100 | * Period calendar month * Report Submission Fee USD 50 * Late Report Submission Fee USD 5,000 per month * Chargeback Fee USD 0 |
| Master Card | ECM | * CTR 1.50% * Chargebacks Count 100 | * Period two consecutive calendar months * Report Submission Fee USD 100 * Late Report Submission Fee from USD 500 to USD 1,000 per day * Chargeback Fee USD 25 for Chargebacks exceeded 1.5% * Period first through sixth month * Report Submission Fee USD 100 * Late Report Submission Fee from USD 500 to USD 1,000 per day * Chargeback Fee USD 25 for Chargebacks exceeded 1.5% * Period seventh through twelfth month * Report Submission Fee USD 100 * Late Report Submission Fee from USD 500 to USD 1,000 per day * Chargeback Fee USD 25 for Chargebacks exceeded 1.5% * USD 50,000 per month after 12 months |
| Master Card | GMAP Step 1 | * FSDVR 3.00 - 4.99% * Frauds Count 3 * Frauds Amount USD 3,000 | * Period calendar month * Chargeback any fraud transaction NO |
| Master Card | GMAP Step 2 | * FSDVR 5.00 - 7.99% * Frauds Count 4 * Frauds Amount USD 4,000 | * Period calendar month * Chargeback any fraud transaction NO |
| Master Card | GMAP Step 3 | * FSDVR 8.00% * Frauds Count 5 * Frauds Amount USD 5,000 | * Period calendar month * Chargeback any fraud transaction YES * Master Card, at its sole discretion, may extend the chargeback liability period to 12 months |
| Visa | MCMP | * CTR 3.00% * International (or Regional) Chargebacks Count 100 | * Period any month * Chargeback Fee USD 0 |
| Visa | GMCMP | * CTR 2.00% * International (or Regional) Chargebacks Count 200 * International (or Regional) Transaction Count 200 | * Period months 1-3 * Chargeback Fee USD 0 * Period months 4-9 * Chargeback Fee USD 100 - USD 200 * Period beyond month 9 * Chargeback Fee USD 100 - USD 200 * Penalty USD 25,000 |
| Visa | HRCMP Step 1 | * CTR 2.00% | * Period months 1-3 * Chargeback Fee USD 100 * Period months 4-6 * Chargeback Fee USD 150 * Period month 7 and subsequent months * Chargeback Fee USD 150 * Penalty disqualify |
| Visa | HRCMP Step 2 | * CTR 4.00% * International (or Regional) Chargebacks Count 3000 * Merchant is assessed US $1 million or more in GMCMP fees | * Period any month * Penalty disqualify |
| Visa | GMFPP Step 1 | * FSR 2.50% * International Fraud Transaction count 25 * International Fraud Transactions amount USD 25,000 | * Period month 1-3 * Period month 3 and above * Penalty USD 5,000 + USD 5,000 for every next month * Chargeback any fraud transaction YES |
| Visa | GMFPP Step 2 | * FSR 2.50% * International Fraud Transactions amount USD 250,000 | * Period month 1 and above * Penalty USD 5,000 + USD 5,000 for every next month * Chargeback any fraud transaction YES |
| Visa | RMFPP Step 1 | * FSR 7.50% * Regional Fraud Transaction count 15 * Regional Fraud Transactions amount USD 15,000 | * Period month 1-3 * Period month 3 and above * Chargeback any fraud transaction YES |
| Visa | RMFPP Step 2 | * FSR 20.00% * Regional Fraud Transaction count 20 * Regional Fraud Transactions amount USD 40,000 | * Period month 1 and above * Chargeback any fraud transaction YES |
| Am Ex | AECP | * CTR 3.00% | * Period 3 months and above * USD 5 per Disputed Charge if the Merchant is in the Immediate Chargeback Program * USD 15 per Disputed Charge if the Merchant is not in the Immediate Chargeback Program |

#### Fraud programs description

##### Master Card Excessive Chargeback Program

Master Card designed the Excessive Chargeback Program (ECP) to encourage each Acquirer to closely monitor, on an ongoing basis, its chargeback performance at the Merchant level and to determine promptly when a Master Card Merchant has exceeded or is likely to exceed monthly chargeback thresholds.

See [ECP Manual](https://www.mastercard.us/en-us/business/overview/support/rules.html)

###### ECP Definitions

Master Card’s Chargeback-to-Transaction Ratio (CTR)
 
The CTR is the number of Master Card chargebacks received by the Acquirer for a Merchant in a calendar month divided by the number of the Merchant’s Master Card sales Transactions in the preceding month acquired by that Acquirer. (A CTR of 1% equals 100 basis points, and a CTR of 1.5% equals 150 basis points.)
 
Master Card’s Chargeback-Monitored Merchant (CMM)
 
A CMM is a Merchant that has a CTR in excess of 100 basis points and at least 100 chargebacks in a calendar month.
 
Master Card’s Excessive Chargeback Merchant (ECM)
 
A Merchant is an ECM if in each of two consecutive calendar months (the “trigger months”), the Merchant has a minimum CTR of 150 basis points and at least 100 chargebacks in each month. This designation is maintained until the ECM’s CTR is below 150 basis points for two consecutive months.
 
Tier 1 ECM
 
A Merchant is a Tier 1 ECM during the first through sixth month (whether consecutive or non-consecutive) that the Merchant is identified as an ECM.
 
Tier 2 ECM
 
A Merchant is a Tier 2 ECM during the seventh through twelfth month (whether consecutive or non-consecutive) that the Merchant is identified as an ECM.
 

##### Master Card Global Merchant Audit Program

The Global Merchant Audit Program (GMAP) uses a rolling six months of data to identify Master Card Merchant locations that, in any calendar month, meet the following criteria set.

See [SPME Manual](http://www.mastercard.com/us/merchant/pdf/SPME-Entire_Manual_public.pdf)

Tier 1 - Informational Fraud Alert
 
> * Three fraudulent Transactions
> * At least USD 3,000 in fraudulent Transactions
> * A fraud-to-sales dollar volume ratio minimum of 3% and not exceeding 4.99%
Tier 2 - Suggested Training Fraud Alert
 
> * Four fraudulent Transactions
> * At least USD 4,000 in fraudulent Transactions
> * A fraud-to-sales dollar volume ratio minimum of 5% and not exceeding 7.99%
Tier 3 - High Fraud Alert
 
> * Five fraudulent Transactions
> * At least USD 5,000 in fraudulent Transactions
> * A fraud-to-sales dollar volume ratio minimum of 8%

Master Card, at its sole discretion, may extend the chargeback liability period to 12 months. Master Card reserves the right to list the Acquirer ID, Acquirer name, Merchant name, Merchant location, and chargeback liability period of any Tier 3 Merchant in a Global Security Bulletin. When Master Card lists the Acquirer and Merchant information in a Global Security Bulletin, Issuer chargeback rights will apply. Each Issuer then has a right to use message reason code 4849 - Questionable Merchant Activity to charge back to the Acquirer some fraudulent Transactions.

Master Card’s Fraud-to-Sales Dollar Volume Ratio (FSDVR)
 
The FSDVR is the amount of Master Card frauds received by the Acquirer for a Merchant in a calendar month divided by the amount of the Merchant’s Master Card sales Transactions in the same month acquired by that Acquirer.
 

##### Visa Merchant Chargeback Activity Monitoring

Visa’s Chargeback-to-Transaction Ratio (CTR)
 
The CTR is the number of Visa chargebacks received by the Acquirer for a Merchant in a calendar month divided by the number of the Merchant’s Visa sales Transactions in the same month acquired by that Acquirer. Disputes related to Chargeback Reason Code 93, “Merchant Fraud Performance Program”, are excluded from program monitoring.
 

An Acquirer must monitor the Chargeback-to-Transaction volume ratio of its Merchants and identify any Merchant that:

> * Receives more than 100 Chargebacks per month
> * Exceeds a Chargeback-to-Transaction volume ratio of 3%

##### Visa Global Merchant Chargeback Monitoring Program Overview

Visa monitors Merchant Outlets and Acquirers that generate an excessive level of international Chargebacks through the Global Merchant Chargeback Monitoring Program, as noted below and as specified in the Visa Global Merchant Chargeback Monitoring Program (GMCMP) Program Guide. Disputes related to Chargeback Reason Code 93, “Merchant Fraud Performance Program,” are excluded from program monitoring.

A Merchant Outlet is identified in the Global Merchant Chargeback Monitoring Program if it meets or exceeds all of the following monthly performance activity levels:

> * 200 international Chargebacks
> * 200 International Transactions
> * 2% ratio of international Chargebacks to International Transactions

Visa may modify or create new monthly performance levels to respond to different Chargeback and fraud trends that emerge.

Global Merchant Chargeback Monitoring Program Handling Fees
 
Visa assesses an Acquirer a Chargeback handling fee of US $100 for each international Chargeback received for each identified Merchant Outlet once the Merchant has been placed in the Global Merchant Chargeback Monitoring Program. Visa collects the Chargeback handling fee from the Acquirer and disburses US $70 to the Issuer that initiated the Chargeback through the Visa Integrated Billing Statement. Visa retains the balance as an administration fee. If the Acquirer and Merchant have not implemented procedures to reduce Chargebacks, Visa may assess the Acquirer an increased Chargeback handling fee not exceeding US $200 for each international Chargeback received for its Merchant. Visa may, at its discretion, assess the Acquirer Chargeback handling fees for Trailing Chargeback Activity that occurs up to 4 months after Merchant termination, regardless of sales volume.
 
Global Merchant Chargeback Monitoring Program Penalties
 
Visa assesses Global Merchant Chargeback Monitoring Program penalties to the Acquirer, as described in the following tables.
 
Penalties for Global Merchant Chargeback Monitoring Program - Merchant-Level Thresholds
 

| Merchant Outlet meets or exceeds the Chargeback activity thresholds, as specified in Global Merchant Chargeback Monitoring Program Overview, in months 1-3 (month 1 = initial notification) | * Workout Period <sub 1</sub * No fee |
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Merchant Outlet meets or exceeds the Chargeback activity thresholds, as specified in Global Merchant Chargeback Monitoring Program Overview, in months 4-9 | * US $100 per international Chargeback for every month the Merchant meets or exceeds the program thresholds <sub 1</sub * If the Acquirer and Merchant have not implemented procedures to reduce Chargebacks, Visa may assess the Acquirer a fee of US $200 for each international Chargeback received for its Merchant <sub 2</sub |
| Merchant Outlet meets or exceeds the Chargeback activity thresholds, as specified in Global Merchant Chargeback Monitoring Program Overview, beyond month 9 | * US $100 per international Chargeback for every month the Merchant meets or exceeds the program thresholds <sub 1</sub * If the Acquirer and Merchant have not implemented procedures to reduce Chargebacks, Visa may assess the Acquirer a fee of US $200 for each international Chargeback received for its Merchant <sub 2</sub * Acquirer is eligible for US $25,000 review fee * Visa may initiate Merchant disqualification processes against a Merchant Outlet and/or its principals |

<sub>1</sub> The Workout Period is not applicable for Acquirer-level thresholds, High-Risk Merchants, or High-Brand Risk Merchants, as specified in High-Brand Risk Merchant Category Codes

<sub>2</sub> Visa allocates US $70 of each fee to the Issuer via a Funds Disbursement

##### Visa High Risk Chargeback Monitoring Program

A Merchant required to use one of the following Merchant Category Codes is considered high-brand risk:

> * 5962, “Direct Marketing-Travel-Related Arrangement Services”
> * 5966, “Direct Marketing-Outbound Telemarketing Merchants”
> * 5967, “Direct Marketing-Inbound Telemarketing Merchants”
> * 7995, “Betting, including Lottery Tickets, Casino Gaming Chips, Off-Track Betting, and Wagers at Race Tracks”
> * 5912, “Drug Stores, Pharmacies”
> * 5122, “Drugs, Drug Proprietaries, Druggist Sundries”
> * 5993, “Cigar Stores and Stands”, for Merchants that sell cigarettes in a Card-Absent Environment
Global Merchant Chargeback Monitoring Program - High-Brand Risk Merchants - Penalties
 
The following table specifies the penalties per international Chargeback for Acquirers of High-Brand Risk Merchants placed in the Global Merchant Chargeback Monitoring Program.
 

| Merchant meets or exceeds the specified Chargeback ratio <sub 1</sub | * Months 1-3 * US $100 per Chargeback per month for each identified Merchant Outlet <sub 2</sub |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Merchant meets or exceeds the specified Chargeback ratio <sub 1</sub | * Months 4-6 * US $150 per Chargeback per month for each identified Merchant Outlet <sub 2</sub |
| Merchant meets or exceeds the specified Chargeback ratio <sub 1</sub | * Month 7 and subsequent months * US $150 per Chargeback per month for each identified Merchant Outlet <sub 2</sub and Visa may disqualify the Merchant from participation in the Visa Program |
| Visa may disqualify the Merchant from participation in the Visa Program if merchant meets or exceeds the specified Chargeback ratio <sub 1</sub without an effective Chargeback reduction plan, and 2 of the following levels of Chargeback activity are reached: | * Merchant’s Chargeback ratio is 2 or more times the specified Chargeback ratio (Single month) * Merchant is assessed fees for 3,000 or more Chargebacks (Single month) * Merchant is assessed US $1 million or more in Global Merchant Chargeback Monitoring Program fees (When reached) |

<sub>1</sub> The Chargeback ratio threshold is 2%

<sub>2</sub> If the Acquirer and Merchant have not implemented procedures to reduce Chargebacks, Visa may assess the Acquirer a fee of US $200 for each international Chargeback received for its Merchant

Acquirer does not identify a High-Brand Risk Merchant with the correct Merchant Category Code, as specified in “High-Brand Risk Merchant Category Codes”

> * When violation occurs
> * US $25,000 per Merchant per month

##### Visa’s Global Merchant Fraud Performance Program

Applies if a merchant is located in one region and a card is issued in another region.

##### Visa’s Regional Merchant Fraud Performance Program

Applies to transactions where the card was issued in the same region as the merchant is located.

Visa’s Fraud-to-Sales Ratio (FSR)
 
The FSR is the number of Visa frauds received by the Acquirer for a Merchant in a calendar month divided by the number of the Merchant’s Visa sales Transactions in the same month acquired by that Acquirer.
 

##### American Express Chargeback Programs

See [American Express Merchant Reference Guide - U.S.](https://www.americanexpress.com/content/dam/amex/us/merchant/new-merchant-regulations/Reference-Guide_EN_US.pdf)

Some chargebacks arise because merchants are placed in one of Am Ex’s chargeback programs. The company may place you in any of these programs either upon signing your contract or at any time during the term of the agreement. These programs are:

Immediate Chargeback Program
 
This program allows Am Ex to process a chargeback at any time a cardholder disputes a transaction, for any reason other than actual or alleged fraud and without having to first send you an inquiry. You may be placed in this program for one of the following three reasons:
 
> * You choose to enroll in this program to avoid receiving inquiries or disputes.
> * Am Ex places you in this program if you meet the company’s criteria for disproportionate inquiries and chargebacks.
> * Your industry has historically had high rates of customer disputes (not necessarily resulting in chargebacks).
Partial Immediate Chargeback Program
 
Your enrollment in this program allows Am Ex to process chargebacks below a predetermined amount, without having to first send you an inquiry at any time a cardholder disputes a transaction for any reason other than actual or alleged fraud. All disputes for charges that are above that predetermined amount will be processed under the standard policy. You may be placed in this program for one of these three reasons:
 
> * You choose to enroll in this program to avoid receiving inquiries for charges below a specific dollar amount.
> * Your Am Ex agreement stipulates participation in this program.
> * Your industry has historically generated high rates of customer disputes.
Fraud Full Recourse Program
 
This program allows Am Ex to issue chargebacks without first sending you an inquiry at any time it receives a cardholder dispute that is based on actual or alleged fraud. You may be placed in this program for one or more of the following reasons:
 
> * You are classified as a high-risk merchant.
> * Am Ex receives a disproportionately high number of inquiries and chargebacks relative either to your prior history or to industry standards.
> * Your merchant account has been cancelled for being fictitious, prohibited or otherwise in violation of the agreement.
Be advised that the above list of reasons, for which you may be placed in one of Am Ex’s chargeback programs, is not exhaustive. At its sole discretion, the company may place you in any one of them at any time.
 
Excessive dispute fee
 
If, in any three (3) months, the monthly ratio of Disputed Charges to gross Charges (less Credits) at an Establishment exceeds three percent, and thereafter in any month when the Establishment again exceeds this ratio, we may charge the Merchant a fee for each Disputed Charge in excess of this ratio.
 
> * $5 per Disputed Charge if the Merchant is in the Immediate Chargeback Program or
> * $15 per Disputed Charge if the Merchant is not in the Immediate Chargeback Program

#### Visa US Rules

##### Merchant Chargeback Monitoring Program - U.S. Region

Visa monitors the total volume of U.S. Domestic and International Interchange and Chargebacks for a single Merchant Outlet and identifies U.S. Merchants that experience all of the following activity levels during any month:

> * 100 or more interchange transactions
> * 100 or more Chargebacks
> * A 1% or higher ratio of overall Chargeback-to-Interchange volume
For the purposes of the U.S. Merchant Chargeback Monitoring Programs, if an Acquirer submits Interchange for a single Merchant Outlet under multiple names, Visa:
 
> * Groups the Merchant activity
> * Notifies the respective Acquirer of the Interchange grouping

##### Merchant Chargeback Monitoring Program Fees - U.S. Region

Visa assesses Merchant Chargeback Monitoring Program fees to a U.S. Acquirer, as described in the table below.

Merchant Chargeback Monitoring Program Fees - U.S. Region
 

| U.S. Merchant Outlet meets or exceeds the Chargeback activity thresholds specified in “Merchant Chargeback Monitoring Program - US Region” | * Initial Notification - month 0 * No fee |
|----------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds for the month following initial Notification | * Notification - month 1 * US $5,000 for failure to return completed documentation within 10 calendar days of the Notification letter date * US $1,000 per day until completed documentation is received |
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds for the second month | * Notification - month 2 * US $10,000 for failure to respond with an acceptable Chargeback reduction plan within 10 calendar days of the Notification letter date * US $1,000 per day until acceptable Chargeback reduction plan is received |
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds for months 3, 4, and 5 | * US $50 per Chargeback for every month the Merchant continues to meet or exceed the Chargeback thresholds <sub 1</sub |
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds for months 6 and 7 | * US $100 per Chargeback for every month the Merchant continues to meet or exceed the Chargeback thresholds <sub 2</sub |
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds for months 8 and 9 | * US $25,000 review fee * US $100 per Chargeback for every month the Merchant continues to meet or exceed the Chargeback thresholds <sub 2</sub |
| U.S. Merchant Outlet continues to meet or exceed the Chargeback activity thresholds beyond month 9 | * US $100 per Chargeback for every month the Merchant continues to meet or exceed the Chargeback thresholds <sub 2</sub * Merchant and its principals eligible for disqualification proceedings, as specified in “Critical Chargeback Levels - U.S. Region” |

<sub>1</sub> Visa allocates US $40 of each fee to the Issuer via a Funds Disbursement

<sub>2</sub> Visa allocates US $90 of each fee to the Issuer via a Funds Disbursement

##### High-Brand Risk Chargeback Monitoring Program Fees - U.S. Region

Visa assesses High-Brand Risk Chargeback Monitoring Program fees to a U.S. Acquirer, from the date of Notification, as described in the following table
 

| During months 1-3, the Merchant meets or exceeds the Chargeback activity thresholds specified in “High-Brand Risk Chargeback Monitoring Program - U.S. Region” | * US $ 5,000 review fee month * US 100 per Chargeback in months 1-3 <sub 1</sub |
|------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| During months 4-6, the Merchant meets or exceeds the applicable Chargeback ratios specified in <sub 1</sub above | * US $ 150 per Chargeback in months 4-6 <sub 2</sub * US $ 25,000 review fee in month 6 |
| After 6 months in which the Merchant has met or exceeded the Chargeback thresholds specified in “High-Brand Risk Chargeback Monitoring Program - U.S. Region” | * Visa may disqualify the Merchant from participation in the Visa Program |

<sub>1</sub> Visa allocates US $90 of each fee to the Issuer via a Funds Disbursement

<sub>2</sub> Visa allocates US $135 of each fee to the Issuer via a Funds Disbursement

Merchant Disqualification - U.S. Region
 
Visa may disqualify a U.S. Merchant specified in “High-Brand Risk Merchant Category Codes” from participating in the Visa Program if the Merchant:
 
> * Meets or exceeds a critical level of Chargeback activity, as determined by Visa
> * Acts with the intent to circumvent Visa programs
> * Causes harm to the Visa system
> * The Acquirer must pay a US $5,000 non-refundable fee and include it with the appeal letter

#### Acquirer Penalties

##### Acquirer Global Merchant Chargeback Monitoring Program

An Acquirer is identified in the Global Merchant Chargeback Monitoring Program if it meets or exceeds all of the following monthly performance activity levels:

> * 500 international Chargebacks
> * 500 International Transactions
> * 1.5% ratio of international Chargebacks to International Transactions
> * One or more Merchants in the program during the reporting month
Penalties for Global Merchant Chargeback Monitoring Program - Acquirer-Level Thresholds
 

| Acquirer meets or exceeds the Chargeback activity thresholds as specified in Global Merchant Chargeback Monitoring Program Overview | * US $25,000 for every month the Acquirer meets or exceeds the program thresholds |
|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Acquirer meets or exceeds the Chargeback activity thresholds, as specified in Global Merchant Chargeback Monitoring Program Overview, more than 3 times in a rolling 12-month period | * US $50,000 for every month the Acquirer meets or exceeds the program thresholds |
| Acquirer meets or exceeds the Chargeback activity thresholds, as specified in Global Merchant Chargeback Monitoring Program Overview, more than 6 times in a rolling 12-month period | * US $100,000 for each subsequent month the threshold is met or exceeded * Acquirer is eligible for the imposition of Risk Reduction Procedures as specified in Member Risk Reduction Requirements * Visa may apply additional fines for repetitive or willful violations, as specified in Repetitive Violations and Willful Violations |

##### Acquirer Chargeback Monitoring Program - U.S. Region

Visa monitors the total volume of U.S. Domestic and International Interchange and Chargebacks for any U.S. Acquirer that experiences all the following activity levels during any month:

> * 500 or more interchange transactions
> * 500 or more Chargebacks
> * A 1% or higher ratio of overall Chargeback-to-Interchange volume
Visa assesses High-Brand Risk Chargeback Monitoring Program fees to a U.S. Acquirer, from the date of Notification, as described in the following table
 

| Acquirer does not * Identify a High-Brand Risk Merchant with the correct Merchant Category Code * Register a High-Brand Risk Merchant | * US $25,000 per Merchant per month * US $100,000 after 3 violations in calendar year and/or prohibition against signing High-Brand Risk Merchants <sub 1</sub |
|------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Acquirer knowingly signs a disqualified Merchant or any of the disqualified Merchant’s principals | * US $250,000 per month until the Acquirer terminates the Merchant Agreement <sub 1</sub |

<sub>1</sub> Visa may impose conditions on Acquirers for violations of the U.S. Regional Operating Regulations, up to and including termination of the Acquirer program

Visa assesses Acquirer Chargeback Monitoring Program fees to a U.S. Acquirer, as described in the following table.

Acquirer Chargeback Monitoring Program Fees - U.S. Region
 

| Acquirer knowingly attempts to circumvent the provisions of “Acquirer Chargeback Monitoring Program - U.S. Region” | * US $25,000 assessed 60 calendar days after Notification to the Acquirer |
|------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Acquirer meets or exceeds the Chargeback activity thresholds specified in “Acquirer Chargeback Monitoring Program - U.S. Region” | * US $25,000 |
| Acquirer meets or exceeds the Chargeback activity thresholds more than 3 times in a rolling 12-month period | * US $100,000 for each subsequent month that either threshold is exceeded |
| Acquirer has had 3 or more Merchants in the Merchant Chargeback Monitoring Programs for 6 consecutive months | * Daily review fee of at least US $2,500, with a one-week minimum fee of US $17,500, assessed while a review of the Acquirer’s and/or Merchants’ Visa Card-related processing activities is being conducted, as specified in “Acquirer Processing Activity Review - U.S. Region” |
| Acquirer fails to take action on recommendations resulting from a review of the Acquirer’s and/or Merchants’ Visa Card-related processing activities | * US $75,000 minimum |

##### Acquirer Fraud Monitoring Program

Visa monitors an Acquirer to determine disproportionate fraud-to-sales ratios.

An Acquirer exceeding 3 times the worldwide or regional fraud-to-sales ratio for more than one quarter will be considered non-compliant and may be subject, but not limited, to the following fines and penalties:

> * Monetary fines specified in the applicable Visa Regional Operating Regulations
> * Temporary suspension of contracting with new Merchants
> * Termination of membership

##### Acquirer Fraud Performance Monitoring Program Penalty Schedule - AP Region and CEMEA Region

| First violation | * US $25,000 |
|----------------------------------|---------------------------------------------------------------------------------------------------------------|
| Second consecutive violation | * US $50,000 |
| 3 or more consecutive violations | * US $100,000 for every subsequent violation per quarter OR Visa may revoke or suspend the Acquirer’s license |

##### Acquirer Fraud Monitoring Program Fines - U.S. Region

| First month | * US $25,000 |
|------------------------------|----------------|
| Second month | * US $50,000 |
| Third month | * US $75,000 |
| Fourth and subsequent months | * US $100,000 |

##### Risk Identification Service Online Conditions and Fees - U.S. Region

Visa may:

> * Impose conditions on a U.S. Acquirer if any of its Merchants are designated as an Identified Merchant by RIS Online
> * Assess a daily review fee of at least US $2,500, with a one-week minimum fee of US $17,500, if an onsite review is required
If Visa determines that a U.S. Acquirer or its Merchant changed, modified, or altered Merchant data in any way to avoid detection by Risk Identification Service (RIS) Online, Visa may assess a US $25,000 fee to the Acquirer for each occurrence identified.
 
Visa assesses the following fines, as specified in the table below, to a U.S. Acquirer after the 3-month Workout Period, as described in “Excessive Fraud Activity Notification - U.S. Region.”
 

| Fine Period - month 1 <sub 1</sub Acquirer receives Excessive Fraud Activity Notification <sub 2</sub | * US $10,000 |
|------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Fine Period - month 2 or 3. Acquirer receives Excessive Fraud Activity Notification <sub 2</sub | * US $25,000 |
| Fine Period - month 4. Acquirer receives Excessive Fraud Activity Notification <sub 2</sub | * US $50,000 |
| Fine Period - month 5. Acquirer receives Excessive Fraud Activity Notification <sub 2</sub | * US $75,000 |
| Fine Period - month 6. Acquirer receives Excessive Fraud Activity Notification <sub 2</sub | * US $50,000 |
| Fine Period - beyond month 6. Acquirer receives subsequent Excessive Fraud Activity Notification (s) <sub 2</sub | * US $100,000 per month \* Merchant and its principal (s) eligible for disqualification proceedings, as specified in “Critical Chargeback Levels - U.S. Region” |

<sub>1</sub> The Risk Identification Service Online remediation process, including Notification requirements, is described in “Excessive Fraud Activity Notification - U.S. Region.”

<sub>2</sub> An Identified Merchant must remain below RIS Online Notification thresholds that incur a fine for at least 3 consecutive months for the Acquirer to exit the fine period specified in this table.

#### Fraud reasons

| Code | Reason | Description |
|--------|-----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 00 | Lost Fraud | A fraudulent transaction that occurs with the use of a lost credit or debit card (or other device accessing a credit or debit card account for example convenience and balance transfer checks) without the actual implied or apparent authority of the cardholder. |
| 01 | Stolen Fraud | A fraudulent transaction that occurs with the use of a stolen credit or debit card (or other device accessing a credit or debit card account for example convenience and balance transfer checks) without the actual implied or apparent authority of the cardholder. |
| 02 | Never Received Issue | The interception and use of a credit or debit card (or other device accessing credit or debit card account for example convenience and balance transfer checks) before receipt by the cardholder by a person without the actual implied or apparent authority of the cardholder. |
| 03 | Fraudulent Application | A fraudulent transaction that occurs with the use of a credit or debit card that was obtained with an application using a false name or other false identification information. |
| 04 | Counterfeit Card Fraud | The use of altered or illegally reproduced credit or debit card (or other physical device accessing a credit or debit card account for example convenience and balance transfer checks) including the replication or alteration of the magnetic stripe or embossing. |
| 05 | Account Takeover Fraud | An existing credit or debit account is used without the actual implied or apparent authority of the cardholder by a person who gains access to and use of the account through an unauthorized means such as a change of address or request for re-issuance of credit or debit cards (or other device for accessing a credit or debit account for example convenience and balance transfer checks) but not lost or stolen cards. |
| 06 | Card Not Present Fraud | A fraudulent transaction that occurs with the use of credit or debit account information including pseudo-account information without the physical card or other device being involved via the phone mail Internet or other electronic means without the actual implied or apparent authority of the cardholder. |
| 07 | Multiple Imprint Fraud | A fraudulent transaction that occurs with a credit or debit card where the merchant having completed a legitimate face-to-face transaction deposits one or more additional transactions without the actual implied or apparent authority of the cardholder. For example the merchant makes several imprints of a card on paper formsets or produces terminal receipts upon receiving additional online or offline card-read authorization approvals. |
| 51 | Bust-out Collusive Merchant | A collusive cardholder engaging in transactions with a collusive merchant as defined in the Cardholder-Merchant Collusion Program. |

#### Chargeback reasons

| Code | Reason | Description |
|--------|-------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 30 | Services Not Provided or Merchandise Not Received | Merchant was unable or unwilling to provide services or Cardholder or authorized person did not receive the merchandise at the agreed-upon location or by the agreed-upon date. Required documents: Documentation to prove that Cardholder received services or proof that merchandise or ticket was received by Cardholder or authorized person on agreed-upon date or at agreed-upon location. Time frame: 120 days from the Transaction Processing Date or the date that the Cardholder expected to receive the service. |
| 41 | Cancelled Recurring Transaction | The Merchant continued to charge a Cardholder for a Recurring Transaction despite notification of cancellation. Required documents: Documentation to prove that service was not cancelled 15 calendar days prior to the Transaction Processing Date and documentation showing portion or amount of services or merchandise used. Time frame: 120 days from the Transaction Processing Date. |
| 4801 | Requested Transaction Data Not Received | Retrieval Request was not fulfilled. Required documents: Copy of Transaction Receipt. Time frame: 60 days from Retrieval request date. |
| 4802 | Requested/Required Information Illegible or Missing | The Received a Transaction Receipt and the Account Number or amount is illegible. Required documents: Copy of Transaction Receipt. Time frame: 120 days from the Transaction Processing Date. |
| 4807 | Warning Bulletin File | The card was listed on electronic Warning Bulletin File however the Merchant completed the transaction. Required documents: None. Time frame: 45 days from the Transaction Processing Date. |
| 4808 | Requested/Required Authorization Not Obtained | The transaction amount exceeded the floor limit established by Master Card but the Authorisation was not obtained or was declined. Required documents: None. Time frame: 45 days from the Transaction Processing Date. |
| 4812 | Account Number Not on File | Transaction did not receive Authorization and was processed using an Account Number that does not match any on the Issuer. Required documents: None. Time frame: 45 days from the Transaction Processing Date. |
| 4831 | Transaction Amount Differs | The cardholder states that he or she was billed an incorrect amount. Required documents: Copy of the transaction receipt and proof to support that the cardholder is responsible for the disputed amount. Time frame: 120 days from the Transaction Processing Date. |
| 4834 | Duplicate Processing | The same transaction was processed more than once. Required documents: Copies of two different transaction receipts. Time frame: 120 days from the Transaction Processing Date. |
| 4835 | Card Not Valid or Expired | A Merchant completed the Transaction with a Card that expired prior to the Transaction Date and the Merchant did not obtained Authorization. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4837 | No Cardholder Authorization | A Merchant did not obtained an Imprint and a signature (or a PIN) in a Card-Present Environment and the Merchant complited the Transaction without the Card holder’s permission or a Transaction was processed with a Fictitious Account Number or no valid Card was outstanding bearing the Account Number or the Transaction Receipt. Required documents: Evidence of both: an Imprint, a signature or PIN. Time frame: 120 days from the Transaction Processing Date. |
| 4840 | Fraudulent Processing of Transactions | Multiple Transactions occurred on a single Card at the same Merchant Outlet without the Cardholder’s permission. Required documents: All transaction receipts and merchant explanation. Time frame: 120 days from the Transaction Processing Date. |
| 4841 | Cancelled Recurring Transaction | The card acceptor continued to bill a cardholder for a recurring transaction after receiving notification of cancellation from the cardholder or issuer or the issuer listed the cardholder. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4842 | Late Presentment | Transaction was not processed within the required time limits. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4846 | Correct Transaction Currency Code Not Provided | The acquirer did not transmit the correct transaction currency code. The transaction occurred in a dual currency environment and a transaction currency is not specified on the transaction receipt. A cardholder was not given the opportunity to choose the desired currency in which the transaction was completed or did not agree to the currency of transaction. Required documents: Documentation proving the correct currency was provided or specified. Time frame: 120 days from the Transaction Processing Date. |
| 4847 | Requested/Required Authorization Not Obtained and Fraudulent Transaction | The transaction amount exceeded the floor limit established by Master Card but the Authorisation was not obtained or was declined and the transaction is fraudulent. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4849 | Questionable Merchant Activity | Issuers can use this chargeback only if the acquirer processed a transaction for a card acceptor that later was listed in a Master Card Global Security Bulletin for violating Master Card rules. Required documents: None. Time frame: 120 calendar days from the Global Security Bulletin publication date. |
| 4850 | Credit Posted as a Purchase | Cardholder account has been inaccurately posted with a debit instead of a credit as a result of an incorrect transaction code or keying error. Required documents: The acquirer must provide a copy of the TID as proof of the retail sale instead of a credit. Time frame: 120 days from the Transaction Processing Date. |
| 4853 | Cardholder Dispute | Cardholder returned (or attempted to return) goods or services to a card acceptor because it was not as decribed. Required documents: Copy of the TID or invoice (if applicable). Card acceptor. Time frame: 120 calendar days from the Transaction Processing Date or the date of receipt of goods and services if delayed delivery. |
| 4855 | Nonreceipt of Merchandise | Cardholder or his or her authorized representative did not receive goods that were to be shipped or delivered. Required documents: Proof that the cardholder or person that the cardholder authorized received the merchandise. Time frame: 120-calendar day time frame is calculated from either the Transaction processing Date of the presented transaction or the latest anticipated delivery date. |
| 4857 | Card-Activated Telephone Transaction | The issuer. Required documents: Additional or corrected information to resolve billing discrepancy. Time frame: 120 days from the Transaction Processing Date. |
| 4859 | Services Not Rendered | The card acceptor is unwilling or unable to render services. The cardholder paid for services or goods by other means. The cardholder received none or only a part of an ATM cash disbursement. The cardholder did not receive airline transportation. Required documents: Proof that the services were rendered or that the card acceptor is able to render them. Appropriate card acceptor explanation. Documentation that verifies the disbursement of funds. Time frame: 120 days from the Transaction Processing Date. |
| 4860 | Credit Not Processed | Card acceptor has not posted a credit to his or her account or that the card acceptor posted a credit and reduced the amount of the credit due without proper disclosure. Required documents: Card acceptor rebuttal (for example, the card acceptor rebuttal states that the merchandise was never returned or that the cancellation was not accepted) or proper disclosure given at the point of int. Time frame: 120 days from the Transaction Processing Date. |
| 4862 | Counterfeit Transaction Magnetic Stripe POS Fraud | Fraudulent transaction and that the cardholder or a person authorized by him or her was in possession of all cards issued with the account on the transaction date. Required documents: Evidence of both: an Imprint, a signature or PIN. Time frame: 120 days from the Transaction Processing Date. |
| 4863 | Cardholder Does Not Recognize | The Cardholder does not recognize the Transaction. Required documents: Copy of Transaction Receipt. Time frame: 120 days from the Transaction Processing Date. |
| 4870 | Chip Liability Shift | A counterfeit card-present transaction was processed to chip card on non-EMV terminal and both the issuer and the acquirer are located in a country or region that has adopted a chip liability shift program. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4871 | Chip/PIN Liability Shift | A fraudulent transaction resulted from the use of a hybrid PIN-preferring card at a magnetic stripe-reading-only terminal (whether PIN-capable or not) or at a chip-capable terminal not equipped with a PIN pad capable (at a minimum) of checking the PIN offline and both the issuer and the acquirer are located in a country or region that has adopted a chip liability shift program. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 4899 | Domestic Chargeback Dispute (Europe Region Only) | Issuers only may use message reason code 4899 in the case of a centrally acquired domestic transaction or a domestic transaction processed through Banknet or EPS-Net where a chargeback is available according to the applicable domestic rule but cannot be processed under a different message reason code. Required documents: With accordance with domestic rule. Time frame: With accordance with domestic rule. |
| 53 | Not as Described or Defective Merchandise | The Cardholder received damaged or defective merchandise or the merchandise or service did not match what was described on the Transaction Receipt or other documentation presented at the time of purchase. Required documents: Documents to prove that the service or merchandise was correctly described and was not defective. Proof that the service was not cancelled and was used by the cardholder or proof that the merchandise. Time frame: 120 days from the Transaction Processing Date. |
| 57 | Fraudulent Multiple Transactions | Multiple Transactions occurred on a single Card at the same Merchant Outlet without the Cardholder’s permission. Required documents: Evidence that fraudulent multiple Transactions did not occur. Evidence that Transactions represent valid delayed or amended charges for T&E Transaction. Time frame: 120 days from the Transaction Processing Date. |
| 60 | Illegible fulfillment | The Received a Transaction Receipt and the Account Number or amount is illegible. Required documents: Legible copy of the Transaction Receipt. Time frame: 120 days from the Transaction Processing Date. |
| 62 | Counterfeit Transaction | A Counterfeit Card was used for a Magnetic stripe or Chip-initiated transaction that received Authorization but the Authorization Request did not include the required data or contained altered data. A counterfeit card-present transaction was processed to chip card on non-EMV terminal and both the issuer and the acquirer are located in a country or region that has adopted a chip liability shift program. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 70 | Card Recovery Bulletin or Exception file | A Merchant did not check the Card Recovery Bulletin or Exception File for a Transaction with an amount that was below the Floor Limit. Required documents: None. Time frame: 75 days from the Transaction Processing Date. |
| 71 | Declined Authorization | A Merchant completed the Transaction after an Authorization Request received a Decline Response. Required documents: None. Time frame: 75 days from the Transaction Processing Date. |
| 72 | No Authorization | Authorization was required for the Transaction but the Merchant did not obtain Authorization. Required documents: None. Time frame: 75 days from the Transaction Processing Date. |
| 73 | Expired Card | A Merchant completed the Transaction with a Card that expired prior to the Transaction Date and the Merchant did not obtained Authorization. Required documents: Documentation to prove the card was not expired on the Transaction Date. Time frame: 75 days from the Transaction Processing Date. |
| 74 | Late Presentment | Transaction was not processed within the required time limits and the account was not in good standing on the Chargeback. Processing Date or the Transaction was processed more than 180 calendar days from the Transaction Date. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 75 | Transaction not Recognized | The Cardholder does not recognize the Transaction. Required documents: Copy of Transaction Receipt. Time frame: 120 days from the Transaction Processing Date. |
| 76 | Incorrect currency or Transaction Code or Domestic Transaction processing violation | Transaction was processed with an incorrect Transaction code or an incorrect currency code or the Merchant did not deposit a Transaction Receipt in the country where the Transaction occurred or the Cardholder was not advised that Dynamic Currency Conversion would occur or was refused the choice of paying in the Merchant. Required documents: Transaction Receipt or other record that proves that the Transaction was correct. Time frame: 120 days from the Transaction Processing Date. |
| 77 | Non-matching Account Number | Transaction did not receive Authorization and was processed using an Account Number that does not match any on the Issuer. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 78 | Service Code Violation | Authorization was not obtained for a Magnetic-Stripe read Transaction on a Visa Electron Card or on a Visa Card in a registered mandatory positive Authorization account range. Required documents: None. Time frame: 75 days from the Transaction Processing Date. |
| 80 | Incorrect Transaction Amount or Account Number | Transaction amount is incorrect or an addition or transposition error was made when calculating the Transaction amount or Merchant altered the Transaction amount after the Transaction was completed without the consent of the Cardholder or a Transaction was processed using an incorrect Account Number. Required documents: Transaction Receipt or other record to prove that Transaction Amount and Account number was correct. Time frame: 120 days from the Transaction Processing Date. |
| 81 | Fraud - Card-Present Environment | A Merchant did not obtained an Imprint and a signature (or a PIN) in a Card-Present Environment and the Merchant complited the Transaction without the Card holder’s permission or a Transaction was processed with a Fictitious Account Number or no valid Card was outstanding bearing the Account Number or the Transaction Receipt. A fraudulent card-present transaction was processed to lost/stolen chip card on non-EMV terminal and both the issuer and the acquirer are located in a country or region that has adopted a chip liability shift program. Required documents: Transaction Receipt or other record to prove separate Transactions were processed and a proof that the transactions were not for the same service or merchandise. Time frame: 120 days from the Transaction Processing Date. |
| 82 | Duplicate Processing | A single Transaction was processed more than once. Required documents: Evidence of Imprint and signature or PIN. Compelling evidence that the cardholder participated in the Transaction. Time frame: 120 days from the Transaction Processing Date. |
| 83 | Fraud - Card-Absent Environment | A Mail/Phone Order Recurring or Electronic Commerce Transaction was processed without the Cardholder’s permission or a Fictitious Account Number was used or no valid Card was outstanding bearing the Account number on the Transaction Receipt. Required documents: Proof that the service was not cancelled and was used by the cardholder or proof that the merchandise was not returned. Proof that cancellation palicy was correctly described. Time frame: 120 days from the Credit Transaction Processing Date. |
| 85 | Credit Not Processed | A Merchant did not process a Credit Transaction Receipt as required. Required documents: Documents (other than Transaction Receipt) to prove that Merchant did not receive payment by other means for the same merchandise or service. Time frame: 120 days from the Transaction Processing Date. |
| 86 | Paid by Other Means | Merchandise or service was received but paid by other means. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 90 | Non-Receipt of Cash or Load Transaction Value at ATM or Load Device | Cardholder did not receive or received only a portion of cash or Load Transaction value. Required documents: Evidence of both: an Imprint, a signature or PIN. Time frame: 120 days from the Transaction Processing Date. |
| 93 | Merchant Fraud Performance Program | Visa notified that the Transaction is identified by the Merchant Fraud Performance Program. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 96 | Transaction Exceeds Limited Amount | An Unattended Acceptance Terminal that performs Cardholder-Activated Transaction Type A or Cardholder-Activated Transaction Type B exceeded the allowed amount. Required documents: None. Time frame: 120 days from the Transaction Processing Date. |
| 28 | Request for Copy Bearing Signature | The cardholder’s bank requests a copy of the transaction receipt from the merchant for fraud analysis. |
| 33 | Fraud Analysis Request | The cardholder’s bank requests a copy of the receipt from the merchant for fraud analysis. |
| 79 | Requested Transaction Information Not Received | This chargeback occurs when a merchant does not respond to a retrieval request within the specified time frame or does not provide a legible response. |
| 5621 | Sales Draft Chargeback | Sales Draft Chargeback. |
| 10 | Fraud | Fraud. |
| 10.1 | EMV Liability Shift Counterfeit Fraud | EMV Liability Shift Counterfeit Fraud. |
| 10.2 | EMV Liability Shift Non-Counterfeit Fraud | EMV Liability Shift Non-Counterfeit Fraud. |
| 10.3 | Other Fraud-Card Present Environment | Other Fraud-Card Present Environment. |
| 10.4 | Other Fraud-Card Absent Environment | Other Fraud-Card Absent Environment. |
| 10.5 | Visa Fraud Monitoring Program | Visa Fraud Monitoring Program. |
| 11.1 | Card Recovery Bulletin | Card Recovery Bulletin. |
| 11.2 | Declined Authorization | Declined Authorization. |
| 11.3 | No Authorization | No Authorization. |
| 12.1 | Late Presentment | Late Presentment. |
| 12.2 | Incorrect Transaction Code | Incorrect Transaction Code. |
| 12.3 | Incorrect Currency | Incorrect Currency. |
| 12.4 | Incorrect Account Number | Incorrect Account Number. |
| 12.5 | Incorrect Amount | Incorrect Amount. |
| 12.6 | Duplicate Processing/Paid by Other Means | Duplicate Processing/Paid by Other Means. |
| 12.7 | Invalid Data | Invalid Data. |
| 13 | Consumer Dispute | Consumer Dispute. |
| 13.1 | Merchandise / Services Not Received | Merchandise / Services Not Received. |
| 13.2 | Cancelled Recurring | Cancelled Recurring. |
| 13.3 | Not as Described or Defective Merchandise/Services | Not as Described or Defective Merchandise/Services. |
| 13.4 | Counterfeit Merchandise | Counterfeit Merchandise. |
| 13.5 | Misrepresentation | Misrepresentation. |
| 13.6 | Credit Not Processed | Credit Not Processed. |
| 13.7 | Cancelled Merchandise/Services | Cancelled Merchandise/Services. |
| 13.8 | Original Credit Transaction Not Accepted | Original Credit Transaction Not Accepted. |
| 13.9 | Non-Receipt of Cash or Load Transaction Value | Non-Receipt of Cash or Load Transaction Value. |
| 501 | Non-JCB Card | This chargeback occurs when a valid authorization was not obtained from the Issuing bank and the card information embossed on or encoded in the magnetic stripe of the card does not conform to JCB’s card specification. This chargeback may be reversed by supplying proof that a valid authorization was obtained at the time of the sale along with a signed swiped or imprinted sales draft that conforms to JCB specifications or evidence that a credit was issued. |
| 502 | Card-Member Dispute | This chargeback occurs when a cardholder disputes goods received or services rendered. This chargeback may be reversed by supplying a written rebuttal which provides proof that the goods/services described on the sales receipt or invoice were suitable there was proper disclosure at the time of purchase or evidence that a credit was issued. |
| 503 | Expired JCB Card | This chargeback occurs when the card used in a transaction expired before the transaction date and the sale is processed without a valid authorization. This chargeback may be reversed by supplying proof that a valid authorization was obtained at the time of the sale along with a signed swiped or imprinted sales draft that provides a valid expiration date for the card at the time of the sale or evidence that a credit was issued. |
| 507 | Incorrect Transaction Amount | This chargeback occurs when the incorrect transaction amount is entered for a sale. This chargeback may be reversed by supplying proof that the transaction amount is correct and/or a legible copy of the signed swiped or imprinted sales draft or evidence that a credit was issued. |
| 510 | Mis-Post | This chargeback occurs when a credit transaction incorrectly posts as a debit or a debit posts as a credit to the cardholder’s account. |
| 512 | Duplicate Processing | This chargeback occurs when a cardholder states that they were charged twice for the same transaction. This chargeback may be reversed by supplying two separate signed sales drafts for each transaction or evidence that a credit has been issued. |
| 513 | Credit Not Received | This chargeback occurs when a customer indicates they have not received a credit to their account. This chargeback may be reversed by supplying proof that the credit has been issued to this account or a signed sales receipt stating your refund policy at the time of purchase or evidence that a credit has been issued. |
| 516 | Non-Receipt of Requested Item | This chargeback occurs when a customer claims they did not receive merchandise which was to be delivered or goods were paid for by other means. This chargeback may be reversed by supplying proof of delivery signed by the cardholder a signed swiped draft proving the cardholder picked up the merchandise or evidence that a credit has been issued. |
| 517 | Requested Copy Illegible | This chargeback occurs when the Issuer of an account requests a copy of a transaction receipt on behalf of the cardholder and a legible copy of the draft requested was not received. This chargeback may be reversed by supplying a legible copy of the signed swiped or imprinted draft that was requested or evidence that a credit has been issued. |
| 521 | Transaction Exceeds Floor limit | This chargeback occurs when a transaction exceeds the relevant floor limit that applies without a valid authorization at the time of the sale or the transaction amount that exceeds the relevant floor limit is greater than the authorized amount. This chargeback may be reversed by supplying proof of a valid authorization for the transaction or any amount that is greater than your assigned floor limit or evidence that a credit has been issued. |
| 522 | Authorization Declined | This chargeback occurs when a transaction for an account was processed after receiving a decline response. This chargeback may be reversed by supplying proof that a valid authorization was given for the transaction or evidence that a credit was issued. |
| 523 | Incorrect Card Number | This chargeback occurs when an account number is provided to the Issuer for a transaction and it does not match any account number in the bank’s master file. This chargeback may be reversed by supplying an imprinted or swiped sales draft which has the same account number as the one that is being disputed. |
| 524 | Addition Error | This chargeback occurs when a cardholder’s copy of the sales draft or other transaction record shows an error in addition which causes the total amount to be incorrect. This chargeback may be reversed by providing proof that the transaction amount is correct and/or a legible copy of the signed swiped or imprinted sales draft or evidence that a credit has been issued. |
| 525 | Altered Amount | This chargeback occurs when a customer claims that the incorrect amount was billed to their account. This chargeback may be reversed by supplying proof that the transaction was processed correctly or evidence that a credit has been issued. |
| 526 | No Signature | This chargeback occurs when a cardholder claims they did not participate in or authorize a transaction to take place. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft proof of delivery signed by the cardholder or evidence that a credit has been issued. |
| 527 | No Imprint | This chargeback occurs when a cardholder claims they did not participate in or authorize a transaction to take place. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft or evidence that a credit has been issued. |
| 534 | Unauthorized Multiple Transactions | This chargeback occurs when two or more transactions take place at one location and the cardholder claims they only authorized or participated in one. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft for all transactions with the cardholder or evidence that a credit has been issued. |
| 536 | Late Submission | This chargeback occurs when more than 45 days have elapsed between the transaction date and the settlement of the sale. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft and the corresponding batch header ticket or evidence that a credit has been issued. |
| 537 | No Show Dispute | This chargeback occurs when a cardholder claims they made a hotel or car rental reservation but one of the following occurred. |
| 538 | Advance Deposit | This chargeback occurs when a cardholder claims that they participated in a transaction for an advance deposit to secure a hotel reservation but one of the following occurred. |
| 541 | Illegible Item | This chargeback occurs when the Issuer of an account requests a copy of a transaction receipt on behalf of the cardholder and a legible copy of the draft requested was not received. This chargeback may be reversed by supplying a legible copy of the signed swiped or imprinted sales draft that was requested or evidence that a credit has been issued. |
| 544 | Cancelled Recurring Transaction | This chargeback occurs when a cardholder claims that the authority to process recurring transactions was cancelled prior to the transaction date. This chargeback may be reversed by supplying proof that the cardholder authorized the transaction or evidence that a credit has been issued. |
| 546 | Unauthorized Purchase | This chargeback occurs when a cardholder claims that they did not participate in or authorize a transaction to take place. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft proof of delivery signed by the cardholder or evidence that a credit has been issued. |
| 547 | JCB Card on Stop List | This chargeback occurs when the JCB card presented for payment was listed on a Stop List that was effective at the time of sale. This chargeback may be reversed by providing proof that the card was not listed on the Stop List at the time of sale or evidence that a credit has been issued. |
| 554 | Non-Receipt of Merchandise/Cash at ATM | This chargeback occurs when a) the cardholder does not receive merchandise at the agreed location or b) the cardholder participated in an ATM transaction but the requested amount of cash was not dispensed to the cardholder. This chargeback may be reversed by supplying proof of delivery showing the cardholder received the merchandise or received the requested amount in the case of an ATM transaction or evidence that a credit has been issued. |
| 580 | Non-Receipt of T&E Documentation | This chargeback occurs when an Issuer did not receive the requested copy of the sales draft within the allowed time frame. This chargeback may be reversed by supplying proof that the requested copy was provided within the allowed time frame or evidence that a credit has been issued. |
| 581 | Split Sale | This chargeback occurs when a transaction requiring an authorization decision was split into two or more card sales to avoid authorization and had the whole sale been submitted for authorization it would have been declined. This chargeback may be reversed by supplying proof that the transaction is not a split sale or that a valid authorization was obtained for the whole amount or evidence that a credit has been issued. |
| 582 | Domestic Transaction | This chargeback occurs when the domestic transaction processed was settled through the International Interchange. This chargeback may be reversed by supplying documentation or information that you feel will assist in reversing the chargeback or evidence that a credit has been issued. |
| 583 | Paid By Other Means | This chargeback occurs when a cardholder paid for a transaction by an alternate method. This chargeback may be reversed by supplying a signed swiped or imprinted sales draft or evidence that a credit has been issued. |
| A01 | Charge Amount Exceeds Authorization Amount | No additional information. |
| A02 | No Valid Authorization | No additional information. |
| A08 | Authorization Approval Expired | No additional information. |
| C02 | Credit Not Processed | No additional information. |
| C04 | Goods/Services Returned or Refused | No additional information. |
| C05 | Goods/Services Canceled | No additional information. |
| C08 | Goods/Services Not Received or Only Partially Received | No additional information. |
| C14 | Paid by Other Means | No additional information. |
| C18 | No Show or CARDeposit Canceled | No additional information. |
| C28 | Canceled Recurring Billing | No additional information. |
| C31 | Goods/Services Not As Described | No additional information. |
| C32 | Goods/Services Damaged or Defective | No additional information. |
| F10 | Missing Imprint | No additional information. |
| F14 | Missing Signature | No additional information. |
| F24 | No Card Member Authorization | No additional information. |
| F29 | Card Not Present | No additional information. |
| F30 | EMV Counterfeit | No additional information. |
| F31 | EMV Lost/Stolen/Non - Received | No additional information. |
| FR2 | Fraud Full Recourse Program | No additional information. |
| FR4 | Immediate Chargeback Program | No additional information. |
| FR6 | Partial Immediate Chargeback Program | No additional information. |
| M01 | Chargeback Authorization | No additional information. |
| M10 | Vehicle Rental - Capital Damages | No additional information. |
| M49 | Vehicle Rental - Theft or Loss of Use | No additional information. |
| P01 | Unassigned Card Number | No additional information. |
| P03 | Credit Processed as Charge | No additional information. |
| P04 | Charge Processed as Credit | No additional information. |
| P05 | Incorrect Charge Amount | No additional information. |
| P07 | Late Submission | No additional information. |
| P08 | Duplicate Charge | No additional information. |
| P22 | Non-Matching Card Number | No additional information. |
| P23 | Currency Discrepancy | No additional information. |
| R03 | Insufficient Reply | No additional information. |
| R13 | No Reply | No additional information. |
| 6321 | No authorize or participate | A chargeback initiated when the cardholder claims they were in possession of a valid card on the date of transactionor she did not authorize or participate in the transaction processed by the merchant. |
| 6323 | Transaction Information Document (TID) | Represents a situation where the cardholder is requesting Transaction Information Document (TID) from the merchant needed for his personal records expense reporting etc. |
| 6341 | Fraud investigation by the bank or issuer | A dispute that is initiated due to a fraud investigation by the bank or issuer. |
| G001 | Recall/Customer Dispute | Recall/Customer Dispute. |

#### Retrieval Request Reasons

| Code | Description |
|--------|---------------------------------------------------------------------------------------------------|
| 3 | Credit Not Received for Tickets/Vouchers |
| 4 | Request Reshipment of Tickets Not Received |
| 7 | Billing was to be in Installments – Credit Due |
| 9 | Customer Requests Return Instructions/Pickup |
| 10 | Partial Credit Received – Remaining Credit Due |
| 11 | Customers Requests Waiving Cancellation Fee – Credit Due |
| 12 | Charged Billed Twice in Error |
| 15 | Requests Credit for Exchange Fee |
| 16 | Requests Credit for Damaged Merchandise |
| 18 | Requests Credit for Overcharge |
| 20 | Claims Cancelled Service – Requests Credit and Discontinue Future Billings |
| 21 | Claims Cancelled Service – Issue Credit or Provide Cancellation Policy and Discontinue Billing |
| 22 | Claims Cancelled Membership – Requests Credit and Discontinue Future Billings |
| 24 | Damaged Merchandise, Requests Return |
| 27 | Order Canceled – Issue Credit or Provide Cancellation Policy/Proof of Delivery |
| 28 | Membership Cancelled in Writing – Issue Credit/supply signed Cancellation Policy & discontinue |
| 29 | Membership Expired – Issue Credit or supply signed contract with renewal policy/expiration date |
| 30 | Defective Merchandise – Credit Requested |
| 31 | Deposit on Vehicle not Purchased, Issue Credit or provide Signed Agreement |
| 33 | Cardholder Does has No Knowledge of Charges, Provide support and itemization or Issue Credit |
| 40 | Service / Membership Cancelled – Credit Requested or Proof of Usage |
| 41 | Unable to contact/cancel – Discontinue Charges |
| 42 | Customer Claims Alternate Bill Arrangement – Requests Credit and Discontinue Future Billings |
| 43 | Request to Cancel Service – Contact Customer Directly |
| 44 | Requests Cancellation of Service – Provide Cancellation instructions/authorization |
| 45 | Requests Replacement for Damaged Merchandise |
| 48 | Requests Replacement for Damaged Merchandise |
| 49 | Deposit on Vehicle not Leased – Issue Credit or Provide signed Agreement |
| 59 | Requests Repair of Damaged Merchandise |
| 60 | Requests Repair of Defective Merchandise |
| 61 | Credit should have been Charge – Bill Customer |
| 62 | Charge should have been Credit – Issue Full Credit |
| 63 | Dissatisfied w/ Good/Service – Credit Requested |
| 70 | Dissatisfied w/ Repair Work on Vehicle – Credit Requested |
| 71 | Requests Credit for Personal Property Damage (Moving services) – Credit Requested |
| 72 | Cardholder has no Knowledge of Billing and it has Wrong Signature |
| 73 | Reservation not Guaranteed, was to be Cancelled – Credit Requested |
| 76 | Cancelled Service – Issue credit or provide copy of agreement and Discontinue Future Billings |
| 77 | Request to Return Merchandise – Provide Return Instructions |
| 78 | Invalid Plastic Number, Provide Valid Number to avoid Chargeback |
| 79 | Invalid Plastic Number, Provide Valid Number to avoid Chargeback |
| 80 | Cancelled Time Share – Credit Requested or provide copy of signed agreement |
| 82 | Customer has No Knowledge of Credit to their Account |
| 83 | Referenced Customer Deceased |
| 86 | Discontinue billings to this Inactive Account |
| 87 | Issue Credit and Discontinue Billing to Inactive Acct |
| 89 | Alternative Billing Arrangements – Credit Requested or provide supporting documentation |
| 90 | Membership/Service Paid in Full – Credit Requested and Discontinue Future Billings |
| 91 | Cancellation Made within Allowable Time – Credit Requested |
| 93 | Cardholder Does Not Recognize Charges |
| 94 | Cardholder Does Not Recognize Charges |
| 95 | Cancelled Service – Credit Requested or provide signed proof serviced were rendered |
| 97 | Customer Requests Credit for Unauthorized Charges |
| 99 | Class/Course Cancelled – Credit Requested |
| 107 | Facility No Longer Open – Credit Requested and Discontinue Future Billings |
| 110 | Calls associated with charges Connected to Wrong Number |
| 117 | Call associated with charges was Cut-off |
| 119 | Cardholder has No Knowledge of CARDeposit Billing – Requests Credit |
| 120 | Requests Credit for Overcharge for Vehicle Rental |
| 121 | Requests Credit for Rental Vehicle did not perform properly |
| 122 | Cardholder has No Knowledge of Vehicle Rental – Issue Credit |
| 123 | Cardholder has No Knowledge of Vehicle Rental – Issue Credit |
| 124 | Customer Requests support for Charges |
| 125 | Cardholder has No Knowledge of Vehicle Rental – Issue Credit |
| 127 | Cardholder Does Not Recognize Charges, Provide Documentation or Issue Credit |
| 128 | Cardholder Claims they did Not Authorize Charges, Provide Documentation or Issue Credit |
| 129 | Cardholder Does Not Recognize Charges, Provide Documentation or Issue Credit |
| 130 | Requests Credit for Deposit not Deducted from Rental Billing |
| 131 | Charge was to be Billed Directly to Insurance company |
| 132 | Customer Billed Twice from separate business addresses |
| 133 | Billed Twice for same Purchase |
| 134 | Customer Claims Portion of Charge was a Deposit |
| 136 | Customer Claims Charge was for Deposit |
| 141 | Customer Claims Charge was Deposit on Vehicle Returned |
| 143 | Customer Claims Flowers ordered Not Received |
| 146 | Disputed Merchandise Returned but 2nd charge processed instead of credit |
| 147 | Customer Claims Billing Paid by Insurance Company |
| 150 | Returned Damaged Merchandise – Provide Documentation or Issue Credit |
| 151 | Returned Damaged Merchandise and Requests Replacement or Credit |
| 152 | Received & Returned Incorrect Merchandise, Provide Documentation or Issue Credit |
| 153 | Received & Returned Incorrect Merchandise and Requests Replacement or Credit |
| 154 | Cancelled Order – Provide Documentation or Issue Credit |
| 155 | Merchandise not Received – Provide Documentation or Issue Credit |
| 156 | Merchandise not Received – Issue Credit and Rebill Upon Delivery |
| 157 | Returned Merchandise but not sent Replacement- Provide Documentation or Issue Credit |
| 158 | Merchandise Returned, Provide Documentation or Issue Credit |
| 159 | Customer Requests signed support and itemization for Charges |
| 160 | Tickets/Vouchers not Ordered – Provide Documentation or Issue Credit |
| 161 | Tickets/Vouchers Returned – Provide Documentation or Issue Credit |
| 162 | Tickets/Vouchers Returned – Provide Documentation or Issue Credit |
| 163 | Tickets/Vouchers Not Received – Provide Documentation or Issue Credit |
| 164 | Tickets/Vouchers unused and Lost or Stolen – Provide Documentation or Issue Credit |
| 165 | Tickets/Vouchers Lost or Stolen – Provide Documentation or Issue Credit |
| 166 | Requests Credit for Payment made directly to establishment, |
| 167 | Reservation Confirmed on Incorrect Date – Provide Documentation or Issue Credit |
| 168 | Reservation Confirmed in Incorrect Location – Provide Documentation or Issue Credit |
| 169 | Incorrect Conversion Rate Used – Provide Documentation or Issue Credit |
| 170 | Cancelled Reservation – Provide Documentation or Issue Credit |
| 171 | Assured Reservation Not Honored – Provide Documentation or Issue Credit |
| 173 | Requests Credit for Duplicate Billing |
| 174 | Customer Requests signed support and itemization for Charges |
| 175 | Customer Requests Credit for a Charge |
| 176 | Cardholder Does Not Recognize the referenced Charges |
| 177 | Cardholder Claims Charge Unauthorized |
| 178 | No Merchandise Ordered or Delivered – Provide Documentation or Issue Credit |
| 179 | Cardholder Does Not Recognize Charge for Reservation |
| 180 | Cardholder Does Not Recognize Charge for stay at Establishment. |
| 181 | No Knowledge of Referenced No Show Charge |
| 182 | Cardholder Question Charges for Damages at Establishment |
| 183 | Cardholder Does Not Recognize Charges from Establishment |
| 184 | Charges identified as Cash Advances – cannot be billed through Am Ex |
| 185 | Purchased but refused Delivery – Provide Documentation or Issue Credit |
| 186 | Incorrect Merchandise – Issue Credit and provider Return Instructions |
| 187 | Requests Replacement for Incorrect Merchandise |
| 188 | Cardholder has no Knowledge of Charge, Requests Credit |
| 189 | No Subscription Issues Received – Provide Documentation or Issue Credit |
| 190 | No Subscription Issues Received – Request to begin Delivery |
| 191 | Merchandise not Ordered or Received – Provide Documentation or Issue Credit |
| 192 | Customer Requests signed support and itemization for Charges |
| 193 | Charges Incurred at establishment are Fraudulent |
| 194 | Charges Incurred at establishment are Fraudulent – Full Magnetic Stripe data not received |
| 195 | Customer Doesn’t Recognize charge and Requests signed support and itemization for Charges |
| 196 | Cardholder Does Not Recognize Charges, Provide Documentation or Issue Credit |
| 197 | Subscription Cancelled yet Billed – Provide Documentation or Issue Credit |
| 198 | Subscription Never Ordered – Provide Documentation or Issue Credit |
| 199 | Cardholder charged for both stay and no-show – Requests Credit for No-show |
| 200 | Sent Claim Report and Request signed support and itemization for Charges |
| 608 | Customer not disputing but requests signed support and itemization of charges |
| 610 | Charge was to be to Third Party – Provide Documentation or Issue Credit |
| 620 | Customer was under billed |
| 656 | No Knowledge of Referenced No-Show/Assured Reservation Charge |
| 657 | Requests Credit for Overcharge |
| 658 | Claims Received Multiple Billings in Error |
| 671 | Billing was to be Complimentary Stay |
| 672 | Customer Doesn’t Recognize delayed charges – Provide Documentation or Issue Credit |
| 673 | Billed Assured Reservation and Actual Stay – Credit Due for Assured Reservation |
| 674 | Invalid or Incorrect Acct Number – Customer Doesn’t Recognize Charge |
| 675 | CARDeposit Billing was to be Applied to the Stay – Provide Documentation or Issue Credit |
| 676 | Cancelled CARDeposit Reservation – Provide Documentation or Issue Credit |
| 678 | Second Request for Credit on Billing |
| 679 | Billed Twice for CARDeposit |
| 680 | Customer Claims Overcharge – Provide Documentation or Issue Credit |
| 681 | Guaranteed Reservation Cancelled within Guidelines – Provide Documentation or Issue Credit |
| 682 | Cancellation of Membership – Provide Documentation or Issue Credit |
| 683 | Charge Belongs to another Person due to Am Ex cards being switched |
| 684 | Charge was Paid in Cash – Provide Documentation or Issue Credit |
| 685 | Customer Requests Copy of Signed Receipt |
| 687 | Does Not Recognize Charge, Provide Documentation or Issue Credit |
| 688 | Charge was to be Paid by Customer’s Company – Credit and Rebill Correct Party |
| 689 | Reservation Made and paid by Third Party – Provide Documentation or Issue Credit |
| 690 | Not Disputing Charges but requesting support and itemization |
| 691 | Not Disputing Charges but requesting signed support and itemization |
| 692 | Customer should have been billed for only one night – Provide Documentation or Issue Credit |
| 693 | Customer Questions charge for Damages – Provide Documentation or Issue Credit |
| 694 | Dissatisfactory Accommodations, Requests Credit |
| 695 | Payment made directly to Establishment – Provide Documentation or Issue Credit |
| 696 | Car Rental Cancelled – Provide Documentation or Issue Credit |
| 697 | Claims Billed Twice for same Rental Vehicle – Provide Documentation or Issue Credit |
| 698 | Customer Requests support for Rental Charges |
| 699 | Customer should have been billed for only one night – Provide Documentation or Issue Credit |
| 700 | Service Cancelled – Provide Documentation or Issue Credit |
| 701 | Customer Requests Cancellation of Service- Discontinue Future Billings |
| 702 | Customer Received Duplicate Credits |
| 703 | Repair/Replacement was to be covered under warranty – Provide Documentation or Issue Credit |
| 704 | Event Cancelled – Credit due for Tickets not used |
| 705 | Tickets Cancelled – Provide Documentation or Issue Credit |
| 706 | Customer Refused Delivery – Provide Documentation or Issue Credit |
| 707 | Call Associated with Bill had poor transmission quality |
| 708 | Call Associated with Bill was not completed/connected |
| 712 | Services Not Rendered |
| 713 | Duplicate Billing – Provide Documentation or Issue Credit |
| 722 | Customer Does Not Recognize Charge for Stay – Provide Documentation or Issue Credit |
| 723 | Payment made directly to Establishment – Provide Documentation or Issue Credit |
| 730 | Issue Credit for Charge and Discontinue all Future Billings |
| 792 | Customer has no Knowledge of charge – Credit and Discontinue Future Billings |
| 800 | Customer No Longer Disputes Charge (Positive Signal) |
| R040 | Service/Membership Cancelled – Issue Credit and Discontinue Future Billings |
| R041 | Customer Unable to contact and Cancel Service – Discontinue Future Billings |
| R042 | Customer made Alternate Billing Arrangements – Provide Documentation or Issue Credit |
| R043 | Customer Requests Cancellation of Service – Contact Customer Directly |
| R044 | Customer Requests Cancellation Instructions/Authorization- Contact Directly |
| RM05 | Cardholder does not agree to amount billed |
| RM21 | Cardholder does not recognize |
| RM23 | Cardholder Requests Copy |
| RM41 | Require for Legal/Fraud Analysis |
| RM42 | Required for chargeback |
| S06 | Automatic Closure of Inquiry |
| V28 | Cardholder Requests Copy w/ Signature |
| V29 | Charge detail or rental agreement request |
| V30 | Cardholder requests copy |
| V31 | Required for chargeback |
| V32 | Original lost in transit |
| V33 | Required for legal/fraud analysis |
| V34 | Repeat request for copy |
| V35 | Written cardholder demand |
| V36 | Legal process specifies original |
| V37 | Previous copy illegible |
| V38 | Required for paper/handwriting analysis |
| V39 | Repeat request for original |
| V40 | Required for arbitration |
| V78 | Cardholder requests copy with signature |
| V79 | Charge detail or rental agreement request |
| V80 | Cardholder requests copy |
| V81 | Required for chargeback |
| V82 | Original lost in transit |
| V83 | Required for legal/fraud analysis |
| V84 | Repeat request for copy |
| V85 | Written cardholder demand |
| V86 | Legal process specifies original |
| V87 | Previous copy illegible |
| V88 | Required for paper/handwriting analysis |
| V89 | Repeat request for original |
| V90 | Required for arbitration |
| 6305 | Cardholder does not agree with billed amount |
| 6321 | Cardholder does not recognize transaction |
| 6322 | Transaction Certificate (ICC Transaction) |
| 6323 | Transaction Information Document (TID) needed for cardholder’s personal records expense reporting |
| 6341 | Fraud investigation |
| 6342 | Potential chargeback or compliance documentation |
| 6343 | Real-time Substantiation Audit Request (IIAS) |

### Transaction Filters

#### General information

Transaction filters in System are intended for rejection of certain transactions on various reasons. For example, there are filters to check fraud transactions, or to check if the issuer-bank or card number is included in the White List, etc.
 
 
The Transaction filters are managed on a Project-level of the System. To set filters for the Project navigate to Fraud protection filters in the Project menu.
 
 

 
The icon to the left from the filter name displays it’s status. To turn a filter ON/OFF click on this icon.
 
Filter’s details are available by clicking on the Configure button.
 
 
The number (or multiple numbers) in “**Error codes**” is called decline-code, or the code of transaction’s rejection reason. This code will be displayed on the Orders screen if the transaction will get the Filtered status.
 
Some filters have Scoring. Scoring allows more flexible approach in filtering system and fraud control. Each filter’s score can be set from 0 to 100. Transaction goes through different filters and each triggered filter adds it’s own score to transaction. If transaction reaches 100 score - it gets Filtered; if not - it passes through. Turned OFF filters have 0 score.
 
 
Filters are also available on Endpoint-level of the System. Filter settings on Endpoint-level override Project-level settings.
 
 
Some Filter parameters can be added only from the Order information screen.
 

#### Fraud protection filters

| Rule name | Rule description |
|-----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Technical filters | Technical filters compare two or more merchant requests to detect and prevent duplicate invoice payments. All filters in this category could be applied to requests in a short period of time since the moment of the transaction received by our system. |
| Referral filters | Referral checks allow to establish block and trust lists of both good and bad transaction attributes, affecting the risk score based on a known trend on many different customer attributes. |
| Velocity filters | Velocity checks allow merchants to set velocity thresholds on various customer attributes, controlling how often a customer can attempt transactions. These checks are intended to identify high-speed fraud attacks. Velocity Rules are calculated at the merchant account level. If a merchant has several merchant accounts under their company account, velocity counts do not aggregate across the entire company if not specified additionally. For example: A single credit card is used for 2 transactions in merchant account A and 3 transactions in Merchant Account B. The Velocity Rule counts 2 in Account A and 3 in Account B. An abandonment of the shopper after redirecting to a payment method or 3-D Secure is counted as an attempt and adds to the count for velocity rules as declined transaction. But not all of these abandoned attempts can be found in the payment list, it depends on the exact integration with PSP. |
| Consistency filters | Consistency checks compare two or more transaction attributes with each other. |
| Custom business validations | Additional validations and risk profiles defined by the manager. |

#### Technical filters

##### Detecting and preventing duplicate requests

Merchant request with the same request parameters will be filtered out

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------|------------------------------------------------|
| Checking interval in seconds | max interval in seconds to check duplicate request | Type: int Default: 15 |
| Skip declined transactions | Y - to skip sessions in Filtered or Declined status, N - otherwise | Type: Enum Default: No |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------|
| 10001 | 1007 | Duplicate request |

##### Detecting and preventing duplicate invoices

Merchant request with the same client order ID will be filtered out

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------|-------------------------------------------------|
| Checking interval in seconds | max interval in seconds to check duplicate invoices, set to 0 for infinity | Type: int Default: 30 |
| Skip error transactions | Y - to skip sessions in Error, Failed, Limited or Rejected status, N - otherwise | Type: Enum Default: Yes |
| Skip unapproved transactions | Y - to skip to skip sessions in Filtered, Declined or Cancelled status, N - otherwise | Type: Enum Default: Yes |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------|
| 10048 | 1058 | Duplicate invoice |

##### Detecting and preventing accidental duplicate credit card number usage

Customer request for the current merchant with the same credit card number will be filtered out

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------|-------------------------------------------------|
| Checking interval in seconds | max interval in seconds to check duplicate credit card number usage, values more then 60 seconds are ignored | Type: int Default: 30 |
| Skip declined transactions | Y - to skip sessions in Filtered or Declined status, N - otherwise | Type: Enum Default: Yes |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------|
| 10087 | 1097 | Duplicate credit card |

##### Declined transactions frequency by Credit Card number and Invoice

This check fires when the number of declined transactions associated with exact Credit Card number and Invoice number exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction, all transactions dates are truncated to minutes during window calculation. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 declines in 60 minutes, it fires on the 11th decline in 60 minutes. Counts transactions for Account verification, Sale, Preauth or Transfer transactions in the Filtered or Declined status. The limit is calculated for the current Endpoint if parameter “for all merchant projects” set to N, or for all Merchant Projects if parameter set to Y.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| checking interval in minutes | time frame to calculate declines count in minutes, values more then 24 hours are ignored | Type: int Default: 30 |
| For all Merchant projects | Y - to check transactions for all projects of the current Merchant, otherwise check transactions for current endpoint only | Type: Enum Default: No |
| Maximum declines count | maximum number of declined or filtered transactions allowed | Type: int Default: 2 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------|
| 10009 | 1013 | Too many declines for the same credit card number and invoice |

##### Preventing of repeated withdrawal operations for the same customer

This check fires when there is more than one transaction for one customer in a non-final status at any time. The risk fires on the second transaction if the first transaction is still in a non-final status. The filter works only for projects added to the CMS. Counts reverse transactions, payouts or transfers.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------|
| For all merchant projects | Yes: for all merchant projects No: for current project only | Type: Enum Default: Yes |
| Skip reversals | Yes: reversal transactions are not taken into account No: reversal transactions are taken into account | Type: Enum Default: Yes |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------|
| 10205 | 1215 | Repeated withdrawal request |

##### Preventing new transactions with source card which has previous attempt in unknown status

This check fires when customer tries to perform new card transaction while last transaction with the same source card still has non-final unknown status for past N minutes (max 1 hour). Counts Sale, Preauth or Transfer transactions in unknown status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| Checking interval in minutes | Max interval in minutes to check existing unknown operation | Type: Int Default: 60 |
| For all merchant projects | Y - to check transactions for all projects of the current merchant N - check transactions for current endpoint only | Type: Enum Default: No |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10259 | 1269 | Customer card has previous transactions in unknown status |

##### Detecting and preventing accidental duplicate email usage

Customer request for the current merchant with the same customer email will be filtered out

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------|------------------------------------------------|
| Checking interval in seconds | max interval in seconds to check duplicate email usage, values more then 60 seconds are ignored | Type: Int Default: 30 |
| Skip declined transactions | Y - skip sessions in Declined status N - otherwise | Type: Enum Default: No |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------|
| 10273 | 1284 | Duplicated transaction |

#### Referral filters

When transaction is filtered by merchant blacklist, the API response message will have the following structure: “Transaction declined - please contact support with the following code: {error code}:{error #}”
This message is relevant only for merchant black lists and can be displayed to the customer instead of actual filtering reason.

##### Blacklist check (BL)

Allows blacklisting of specified clients based on various criteria such as email, IP address, etc

Score: No

Enabled by default: Y

**Parameters**

| Name | Description | Value |
|---------------------------|-----------------------------------------------------------------------------------------------------------------------|-------------------------------------------------|
| For all merchant projects | Y - to check blacklists for all projects of the current merchant, otherwise check blacklists for current project only | Type: Enum Default: Yes |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------|
| 10002 | 1022 | Credit card blacklisted |
| 10027 | 1037 | Issuer country in blacklists |
| 10028 | 1038 | Country in blacklist |
| 10033 | 1043 | Email server blacklisted |
| 10068 | 1078 | Email blacklisted |
| 10113 | 1123 | Billing country blacklisted |
| 10123 | 1133 | Issuer country in blacklist for selected payment method |
| 10094 | 1104 | Credit card blacklisted |
| 10029 | 1039 | Credit card issuer blacklisted |
| 10067 | 1077 | Destination credit card blacklisted |
| 10095 | 1105 | Destination credit card blacklisted |
| 10125 | 1135 | Destination credit card issuer blacklisted |
| 10030 | 1040 | IP address blacklisted |
| 10096 | 1106 | IP address blacklisted |
| 10031 | 1041 | Email blacklisted |
| 10097 | 1107 | Email blacklisted |
| 10069 | 1079 | Destination blacklisted |
| 10098 | 1108 | Destination blacklisted |
| 10137 | 1147 | Billing country blacklisted for merchant |
| 10138 | 1148 | IP-address country blacklisted for merchant |
| 10139 | 1149 | Customer e-mail blacklisted for merchant |
| 10140 | 1150 | Customer fingerprint blacklisted for merchant |
| 10141 | 1151 | Customer ip-address blacklisted for merchant |
| 10142 | 1152 | Customer purpose blacklisted for merchant |
| 10143 | 1153 | Destination card bin blacklisted for merchant |
| 10144 | 1154 | Destination card country blacklisted for merchant |
| 10145 | 1155 | Destination card number blacklisted for merchant |
| 10146 | 1156 | Destination card type blacklisted for merchant |
| 10147 | 1157 | E-mail domain blacklisted for merchant |
| 10148 | 1158 | Source card bin blacklisted for merchant |
| 10149 | 1159 | Source card country blacklisted for merchant |
| 10150 | 1160 | Source card number blacklisted for merchant |
| 10151 | 1161 | Source card type blacklisted for merchant |
| 10156 | | Customer e-mail blacklisted for manager |
| 10157 | | Customer fingerprint blacklisted for manager |
| 10158 | | Customer ip-address blacklisted for manager |
| 10159 | | Customer purpose blacklisted for manager |
| 10160 | | Destination card number blacklisted for manager |
| 10161 | | E-mail domain blacklisted for manager |
| 10162 | | Source card number blacklisted for manager |
| 10169 | | Customer e-mail + source card number blacklisted for merchant |
| 10194 | | Source card mask blacklisted for merchant |
| 10195 | | Destination card mask blacklisted for merchant |
| 10196 | | Source card mask blacklisted for manager |
| 10197 | | Destination card mask blacklisted for manager |
| 10271 | | Customer phone number blacklisted for manager |
| 10272 | | Customer phone number blacklisted for merchant |
| 15027 | | Customer e-mail blacklisted for gate |
| 15028 | | Customer fingerprint blacklisted for gate |
| 15029 | | Customer ip-address blacklisted for gate |
| 15030 | | Customer purpose blacklisted for gate |
| 15031 | | Destination card number blacklisted for gate |
| 15032 | | E-mail domain blacklisted for gate |
| 15033 | | Source card number blacklisted for gate |
| 15038 | | Destination card bin blacklisted for processor |
| 15039 | | Destination card country blacklisted for processor |
| 15040 | | Source card bin blacklisted for processor |
| 15041 | | Source card country blacklisted for processor |
| 15062 | | Billing country blacklisted for gate |
| 15063 | | IP-address country blacklisted for gate |
| 15064 | | Destination card country blacklisted for gate |
| 15065 | | Source card country blacklisted for gate |
| 15111 | | Source card mask blacklisted for gate |
| 15112 | | Destination card mask blacklisted for gate |
| 15182 | | Destination card mask extended blacklisted for gate |
| 15183 | | Source card mask extended blacklisted for gate |
| 15184 | | Site URL check failed: blacklisted by processor |
| 15191 | | Source card mask and expiration date blacklisted for gate |
| 18040 | | Source card number blacklisted for processor |
| 18041 | | Destination card number blacklisted for processor |
| 18044 | | Customer purpose blacklisted for processor |
| 18045 | | Customer ip-address blacklisted for processor |
| 18046 | | Customer e-mail blacklisted for processor |
| 18047 | | Customer fingerprint blacklisted for processor |
| 18050 | | Source card mask blacklisted for processor |
| 18051 | | Destination card mask blacklisted for processor |
| 19104 | | Billing address country is in processor black list |

##### Predefined loyalty lists check

Allows processing for trusted customers only. Different merchants have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out. Filter will be applied for chosen countries only, for all other countries check will be ignored.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| BIN country identifier | \* | Type: List Default: \* |
| For all merchant projects | Y - to check customer email in email anti-blacklists for all projects of the current merchant, otherwise check in email list for current project only | Type: Enum Default: Yes |
| Ignore check for account type | \* | Type: String Default: \* |
| Ignore check for bank id list | \* | Type: String Default: \* |
| IP country identifier | apply filter for selected countries only, country defined by customer IP | Type: List Default: \* |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------------------------------|
| 10046 | | Disloyal customer |
| 10152 | 1162 | Merchant loyal customer e-mail check failed |
| 10153 | 1163 | Merchant loyal customer purpose check failed |
| 10154 | 1164 | Merchant loyal destination card number check failed |
| 10155 | 1165 | Merchant loyal source card number check failed |
| 10163 | 1173 | Manager loyal customer e-mail check failed |
| 10164 | 1174 | Manager loyal customer purpose check failed |
| 10165 | 1175 | Manager loyal destination card number check failed |
| 10166 | 1176 | Manager loyal source card number check failed |
| 10168 | 1178 | Merchant loyal customer e-mail + source card number end check failed |
| 10183 | 1193 | Merchant loyal customer e-mail + source card number check failed |
| 10184 | 1194 | Merchant loyal customer phone + source card number check failed |
| 10185 | 1195 | Merchant loyal customer purpose + source card number check failed |
| 10186 | 1196 | Merchant loyal customer fingerprint + source card number check failed |
| 10193 | 1203 | Transaction declined - please contact support with the following code: 1203:10193 |
| 10260 | 1270 | Manager loyal destination card mask check failed |
| 10261 | 1271 | Merchant loyal source card mask check failed |
| 10262 | 1272 | Merchant loyal destination card mask check failed |
| 10263 | 1273 | Manager loyal source card mask check failed |
| 15034 | | Gate loyal customer e-mail check failed |
| 15035 | | Gate loyal customer purpose check failed |
| 15036 | | Gate loyal destination card number check failed |
| 15037 | | Gate loyal source card number check failed |
| 15110 | | Gate loyal card number check failed |
| 15168 | | Gate loyal source card mask check failed |
| 15169 | | Gate loyal destination card mask check failed |
| 15177 | | Gate auto loyal customer email check failed |
| 15178 | | Gate loyal source card mask and expiration date check failed |
| 15179 | | Gate loyal source card mask and country billing check failed |
| 15180 | | Gate loyal source card mask extended check failed |
| 15181 | | Gate loyal destination card mask extended check failed |
| 18042 | | Processor loyal source card number check failed |
| 18043 | | Processor loyal destination card number check failed |
| 18110 | | Processor loyal source card mask check failed |
| 18111 | | Processor loyal destination card mask check failed |

##### Ban untrusted networks

Allows to make block lists based on the specific IP address ranges of the customer. Merchants are able to submit IP address ranges in either IPv4 or IPv6 format via CSV upload.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------|
| Customer ip ranges | file format example: 192.168.0.0, 192.168.255.255 fd00:0000:0000:0000:0000:0000:0000:0000, fdff:ffff:ffff:ffff:ffff:ffff:ffff:ffff | Type: File |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------|
| 10034 | 1044 | Untrusted network |

##### Credit Card Whitelist check (WL)

Allows ignoring all other fraud filters for selected credit cards. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions.
You can whitelist a customer’s credit card so they can successfully process their transaction. White list will be applied only before total transactions amount for the last month for this credit card will not reach the limit specified by filter parameters. White list could be specified for: the exact source card number by manager and merchant, the exact destination card number by merchant or the whole source card number issuer BIN range.

Score: N/A

Enabled by default: Y

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------|
| For all merchant projects | current total transactions amount for the last month for this credit card value would be calculated, - Y: for all projects, - 3D: for 3D gates only, - Non3D: for non 3D gates only, - N: for current project only of the current merchant and converted to current project currency to compare with “up to amount” value | Type: Enum Default: Yes |
| Subtract Cancel transactions | \* | Type: Enum Default: Yes |
| Up to amount | maximum total transactions amount for the last month for this credit card to allow credit card to be whitelisted, if this limit reached - whitelist will be ignored | Type: Decimal Default: 99999999 |

##### Customer fingerprint

Score: Yes

Enabled by default: N

**Parameters**

| Name | Value |
|-----------------------------|-----------------------------------------------------|
| Add to black list threshold | Type: Decimal Default: 10.0 |
| Block transaction threshold | Type: Decimal Default: 3.5 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------|
| 10035 | 1045 | Fraud suspicious activity |
| 10039 | 1049 | Fraud suspicious activity |

##### Check reader entry mode

If reader entry mode not in allowed list and this list is configured - filter declines transaction

Score: No

Enabled by default: N

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------|
| 10088 | 1098 | Incorrect reader entry mode |

##### IP address Country check

This referral list allows the merchant to process transactions only for selected countries based on country of the customer IP address. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------|
| 10014 | 1024 | Country not in trust list |

##### Issuer Country check

This referral list allows the merchant to process transactions only for selected countries based on issuing country of the card. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. Check applied for both Source and Destination card numbers.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------|
| 10015 | 1025 | Issuer country not in trust list |

##### Billing Country check

This referral list allows the merchant to process transactions only for selected countries based on billing country of the customer. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------|
| 10112 | 1122 | Billing country not in trust list |

##### IP address Country blacklist

This referral list allows the merchant to make block lists based on country of the customer IP address. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------|
| 10028 | 1038 | Country in blacklist |

##### Issuer Country blacklist

This referral list allows the merchant to make block lists based on issuing country of the card. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. Check applied for both Source and Destination card numbers.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------|
| 10027 | 1037 | Issuer country in blacklist |

##### Billing Country blacklist

This referral list allows the merchant to make block lists based on billing country of the customer. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------|------------|
| Country identifier | comma separated country identifiers list | Type: List |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------|
| 10113 | 1123 | Billing country in blacklist |

##### Issuer Country blacklist by Payment method

This referral list allows the merchant to make block lists based on issuing country of the card for selected payment method. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. Check applied for both Source and Destination card numbers.

Score: N/A

Enabled by default: N

**Parameters**

| Name | Value |
|--------|-----------------------------------------------|
| | Type: List Default: - |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------|
| 10123 | 1133 | Issuer country in blacklist for selected payment method |

##### Transaction amount check

This check can be used to apply higher risk scores to transactions based on the transaction amount.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Value |
|--------------------|----------------------------------------------------|
| Transaction amount | Type: Decimal Default: 0.0 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------|
| 10032 | 1042 | Incorrect transaction amount |

##### Source Credit Card type check

This referral list allows the merchant to process transactions only for selected Source Credit Card types. Counts Sale and Transfer transactions.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| forbidden card level types | comma separated card level type list. Typical card types: PREPAID, REWARDS, VIRTUAL, CASH, ATM, STANDARD, CLASSIC, GOLD, SIGNATURE, PLATINUM, ELECTRON, CORPORATE, BUSINESS, WORLD, DEBIT and variations like GOLD REWARDS, WORLD CORPORATE, etc. | Type: String Default: PREPAID, REWARD, CORPORATE, BUSINESS |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------|
| 10127 | 1137 | Unsupported product type |

##### Destination Credit Card type check

This referral list allows the merchant to process transactions only for selected Destination Credit Card types. Counts Sale and Transfer transactions.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------|
| forbidden card level types | comma separated card level type list. Typical card types: PREPAID, REWARDS, VIRTUAL, CASH, ATM, STANDARD, CLASSIC, GOLD, SIGNATURE, PLATINUM, ELECTRON, CORPORATE, BUSINESS, WORLD, DEBIT and variations like GOLD REWARDS, WORLD CORPORATE, etc. | Type: String Default: PREPAID, REWARD, CORPORATE, BUSINESS |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------|
| 10129 | 1139 | Unsupported destination product type |

#### Consistency filters

##### Check customer data

If one of the stop words contains in cardholder name or firstname/last name OR if cardholder name or firstname/lastname match the specified regexp OR if customer data failed basic validation rules (in case the validation flag is turned on) - filter declines transaction.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Value |
|------------------------------------------------------|--------------------------------------------------|
| Apply basic validation rules | Type: Enum Default: Y |
| Check if customer first name and last name are equal | Type: Enum Default: N |
| Check if customer first name contains last name | Type: Enum Default: N |
| Check if customer last name contains first name | Type: Enum Default: N |
| Deny regexp | Type: String Default: \* |
| Min customer first name length | Type: Int Default: 0 |
| Min customer last name length | Type: Int Default: 0 |
| Stop word list | Type: String Default: \* |

##### Customer IP address Country differs from Issuing Country

This risk check is triggered when a transaction has the сustomer IP country different from the issuing country of the card. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check. If parameter “apply for countries” is empty, filter will require strict customer country to issuer country matching for all the countries, otherwise this check will force country matching for listed countries only. For example if you setup “apply for countries” to US - check will be triggered for following country combinations US-any NonUS or any NonUS-US, but for combinations any NonUS-any NonUS and US-US the check will not fire. For card2card transactions issuer country of the source card should be equal to issuer country of the destination card, i.e. this check will be triggered for any cross-border transaction.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| apply for countries | if current parameters are not empty, check will be applied for listed countries only | Type: List Default: 0 |
| ignore undefined countries | ignore check if country of the customer or issuer could not be defined | Type: Enum Default: Y |
| skip country identifier | ignore check for specific customer country, for example check could be skipped if customer uses mobile network with Opera browser proxy to process the transaction | Type: List Default: 0 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------------------------------|
| 10013 | 1023 | Country of the customer does not correspond to the country of the issuer |

##### Customer name differs from Cardholder name

This check fires when the provided customer name does not match cardholder name.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------------|-------------------------------------------------------------------------------|----------------------------------------------|
| greatest levenshtein distance | greatest levenshtein distance to consider customer and cardholder names equal | Type: Int Default: 3 |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10114 | 1124 | Customer name does not correspond to the cardholder name |

##### Customer IP address differs from IP address used for 3-D Secure validation

This check fires when the provided Customer IP address does not match IP address used for 3-D Secure validation. Sometimes fraudsters are changing the destination of the payment converting sale operatons (revocable operation) to card2card transfers to their own cards (irrevocable operation). To exclude the automation of such fraud cases this filter could be used. Some providers are using dynamic IP addresses for their clients and during transaction processing customer IP address might be changed slightly. To avoid false positives in such cases IP address change in /24 subnet is allowed.

Score: Yes

Enabled by default: N

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------------|
| 10070 | 1080 | Customer IP address have been changed during transaction processing |

##### Customer birthday check

This check fires when the provided customer birthday is in incorrect format or customer is too young or too old to perform requested operation.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------|
| date format | input format for customers birthday, following macros are allowed - %Y Year, numeric, four digits - %m Month, numeric (00..12) - %d Day of the month, numeric (00..31) | Type: String Default: %Y%m%d |
| maximum age | maximum client age to process the transaction | Type: Int Default: 100 |
| minimum age | minimum client age to process the transaction | Type: Int Default: 16 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------|
| 10086 | 1096 | Invalid customer birthday |

##### Source Credit Card number expiration date check

This check fires when the provided Source Credit Card expiration date will expire soon. The time threshold is a moving window calculated backwards from the moment of the transaction. Usually card expires in the last day of the expiration month printed on card. Check could be used to avoid acceptance of the Credit Card for future preauthorized payments if it expires before the the last recurring payment planned.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------------------|------------------------------------------|----------------------------------------------|
| minimum days before card expiration | minimum days before card expiration date | Type: Int Default: 0 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------|
| 10126 | 1136 | Card expires too soon |

##### The 6+4 customer cards differs from the 6+4 passed in purpose

This check fires when the provided Customer 6+4 card does not match 6+4 passed in purpose. Counts Sale and Preauth transactions in any status.

Score: Yes

Enabled by default: N

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------|
| 10249 | 1259 | Customer card 6+4 does not match the purpose |

#### Custom business validations

##### Transaction amount changing for Purpose

This check fires when the Transaction amount changing associated with exact Purpose exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. So, if you set a quantity threshold of 10 transactions in 30 days, only 10 transactions with amount fitting parameter regexp below will be allowed, starting from 11th transactions its amount should fit regexp after parameter value. Counts Account verification, Sale, Preauth or Transfer transactions in Approved status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|---------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------|
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: N |
| lookup period in days | lookup period to analyse transaction amount velocity in days | Type: int Default: 30 |
| quantity threshold | since specified threshold all transaction amounts should fit “regexp after” parameter value | Type: int Default: 99999 |
| regexp after | regular expression value to fit all transaction amounts, staring from “quantity threshold” parameter value | Type: String Default: ^(2[5-9][0-9]|[3-9][0-9] {2}|[1-9][0-9]{3,10})([.] [0-9]{0,3})?$ |
| regexp below | if transaction amount fits this parameter value, “quantity threshold” current value increased by one | Type: String Default: ^([0-9]{1,2}| 1[0-9]{2}| 2[0-4][0-9])([.][0-9] {0,3})?$ |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------|
| 10080 | 1090 | Invalid transaction amount |

##### Authorization reattempts requirements EMEA

This check fires for all purchase transactions. Merchants that receive a decline response for a transaction will only be allowed to resubmit it for authorization up to fifteen times within 30 calendar days from the date of the original decline response if the response code is one of the following:

* Response Code 100-Decline (general, no comments)
* Response Code 101-Decline, expired card
* Response Code 102-Decline, suspected fraud
* Response Code 104-Decline, restricted card
* Response Code 106-Decline, allowable PIN tries exceeded
* Response Code 107-Decline, refer to card issuer
* Response Code 108-Decline, refer to card issuer’s special conditions
* Response Code 109-Decline, invalid merchant
* Response Code 110-Decline, invalid amount
* Response Code 112-Decline, PIN data required
* Response Code 114-Decline, no account of type requested
* Response Code 115-Decline, requested function not supported
* Response Code 116-Decline, not sufficient funds
* Response Code 117-Decline, incorrect PIN
* Response Code 120-Decline, transaction not permitted to terminal
* Response Code 121-Decline, exceeds withdrawal amount limit
* Response Code 122-Decline, security violation
* Response Code 123-Decline, exceeds withdrawal frequency limit
* Response Code 124-Decline, violation of law
* Response Code 160-Decline, additional customer authentication required
* Response Code 197-Decline, call Am Ex
* Response Code 198-Decline, call Card Processing Centre
* Response Code 903-Status message: re-enter transaction
* Response Code 904-Decline reason message: format error
* Response Code 907-Decline reason message: card issuer or switch inoperative
* Response Code 909-Decline reason message: system malfunction
* Response Code 913-Decline reason message: duplicate transmission
* Response Code 914-Decline reason message: not able to trace back to original transaction
* Response Code 921-Decline reason message: security software/hardware error - no action
* Response Code 950-Decline reason message: violation of business arrangement

International card systems Rules to prohibit acquirers and their recurring services merchants from resubmitting a declined transaction for authorization if it receives a response:

* Response Code 111-Decline, invalid card number
* Response Code 180-Decline, by cardholders wish
* Response Code 200-Pick-up (general, no comments)
* Response Code 207-Pick-up, special conditions
* Response Code 208-Pick-up, lost card
* Response Code 209-Pick-up, stolen card
* Response Code 908-Decline reason message: transaction destination cannot be found for routing

Visa only:

* Response Code 119-Decline, transaction not permitted to cardholder
* Response Code 902-Decline reason message: invalid transaction

Mastercard only:

* Response Code 201-Pick-up, expired card
* Response Code 202-Pick-up, suspected fraud
* Response Code 203-Pick-up, card acceptor contact card acquirer
* Response Code 204-Pick-up, restricted card
* Response Code 205-Pick-up, card acceptor call acquirer’s security department
* Response Code 206-Pick-up, allowable PIN tries exceeded
* Response Code 210-Pick-up, suspected counterfeit card

The time threshold is a moving window calculated backwards from the moment of the transaction. Counts Account verification, Sale, Preauth transactions in Declined status for listed decline reasons. Correct decline reasons should be supported by a connected PSP. Limits are calculated separately for each merchant id, PAN and transaction amount.

Score: No

Enabled by default: N

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------|
| 10182 | 1192 | Payment system authorisation reattempts limit reached |

##### Visa Preauthorized Transaction Decline Response requirements N.A.

This check fires for recurring transactions only. Merchants that receive a decline response for a preauthorized transaction will only be allowed to resubmit it for authorization up to four times within 16 calendar days from the date of the original decline response if the response code is one of the following:

* Response Code 05 - Authorization Declined
* Response Code 51 - Insufficient Funds
* Response Code 61 - Exceeds Approval Amount Limit
* Response Code 65 - Exceeds Withdrawal Frequency Limit

If an approval response is not received within this time frame, merchants must not resubmit the transaction or their acquirers may be subject to non-compliance actions, as outlined in the Visa Rules, and may be subject to chargebacks. Visa Rules to prohibit acquirers and their recurring services merchants from resubmitting a declined transaction for authorization if it receives a pickup response:

* Response Code 04 - Pick Up Card
* Response Code 07 - Pick Up Card, Special
* Response Code 33 - Expired Card, Capture
* Response Code 34 - Suspected Fraud, Retain Card
* Response Code 35 - Card Acceptor, Contact Acquirer, Retain Card
* Response Code 36 - Restricted Card, Retain Card
* Response Code 37 - Contact Acquirer Security Department, Retain Card
* Response Code 41 - Lost Card
* Response Code 43 - Stolen Card
* Response Code 67 - Capture Card

or a decline response of
 
* Response Code 14 - Invalid Account Number (No Such Number)
* Response Code 54 - Expired Card
* Response Code 57 - Transaction Not Permitted

The time threshold is a moving window calculated backwards from the moment of the transaction. Counts Account verification, Sale, Preauth or Transfer transactions in Declined status for listed decline reasons. Correct decline reasons should be supported by a connected PSP. Limits are calculated separately for each gate descriptor.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------|
| apply restriction types | CANCEL (only cancel decline reasons), PICKUP (only pickup decline reasons), DELAY (only time frame delays) | Type: String Default: CANCEL,PICKUP,DELAY |
| ignore period in months | if this parameter value greater zero, only one declined transaction allowed during the specified period, independently from its decline code | Type: Int Default: 0 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10090 | 1100 | Visa rules violation for preauthorized transaction (DELAY) |
| 10135 | 1145 | PSP rules violation for no CVV transaction (CANCEL) |
| 10136 | 1146 | PSP rules violation for no CVV transaction (PICKUP) |

##### MCC 6211 restrictions

Security Brokers/Dealers

[5] American Samoa
 
[7] Angola
 
[9] Antarctica
 
[19] Bangladesh
 
[22] Belgium
 
[24] Benin
 
[26] Bhutan
 
[28] Bosnia and Herzegovina
 
[30] Bouvet Island
 
[32] British Indian Ocean Territory
 
[34] Bulgaria
 
[35] Burkina Faso
 
[36] Burundi
 
[39] Canada
 
[40] Cabo Verde
 
[43] Chad
 
[45] China
 
[46] Christmas Island
 
[47] Cocos (Keeling) Islands
 
[49] Comoros
 
[50] Congo
 
[54] Cote d’Ivoire
 
[60] Djibouti
 
[61] Dominica
 
[66] Equatorial Guinea
 
[67] Eritrea
 
[69] Ethiopia
 
[70] Falkland Islands (Malvinas)
 
[78] Gabon
 
[79] Gambia
 
[85] Greenland
 
[86] Grenada
 
[87] Guadeloupe
 
[91] Guinea
 
[92] Guinea-Bissau
 
[94] Haiti
 
[95] Heard Island and Mc Donald Islands
 
[96] Holy See (Vatican City State)
 
[107] Israel
 
[110] Japan
 
[115] Kosovo
 
[116] Kiribati
 
[121] Lao People’s Democratic Republic
 
[125] Liberia
 
[131] North Macedonia
 
[132] Madagascar
 
[133] Malawi
 
[136] Mali
 
[139] Martinique
 
[140] Mauritania
 
[144] Micronesia, Federated States of
 
[147] Mongolia
 
[151] Mozambique
 
[152] Myanmar
 
[154] Nauru
 
[155] Nepal
 
[157] Netherlands Antilles
 
[158] New Caledonia
 
[161] Niger
 
[163] Niue
 
[164] Norfolk Island
 
[165] Northern Mariana Islands
 
[169] Palau
 
[170] Palestine, State of
 
[176] Pitcairn
 
[179] Puerto Rico
 
[181] Reunion
 
[184] Rwanda
 
[185] Saint Barthelemy
 
[186] Saint Helena, Ascension and Tristan da Cunha
 
[189] Saint Martin (French part)
 
[190] Saint Pierre and Miquelon
 
[194] Sao Tome and Principe
 
[196] Senegal
 
[203] Solomon Islands
 
[206] South Georgia and the South Sandwich Islands
 
[210] Suriname
 
[211] Svalbard and Jan Mayen
 
[217] Tajikistan
 
[220] Timor-Leste
 
[221] Togo
 
[222] Tokelau
 
[223] Tonga
 
[228] Turks and Caicos Islands
 
[229] Tuvalu
 
[238] Vanuatu
 
[240] Viet Nam
 
[243] Wallis and Futuna
 
[244] Western Sahara
 
[246] Zambia
 
[247] Zimbabwe
 
[254] Bonaire, Sint Eustatius and Saba
 
 

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------|------------------------------------------------|-----------------------------------------------|
| allow Australia | allows Australia processing | Type: Enum Default: N |
| allow France | allows France processing | Type: Enum Default: N |
| allow Jamaica | allows Jamaica processing | Type: Enum Default: N |
| allow Master Card for NA | allows Master Card processing for North America | Type: Enum Default: N |
| allow Netherlands | allows Netherlands processing | Type: Enum Default: N |
| allow Uganda | allows Uganda processing | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------|
| 10099 | 1109 | MCC 6211 rules violation |

##### MCC 7995 restrictions

Betting/Casino Gambling

[5] American Samoa
 
[7] Angola
 
[8] Anguilla
 
[9] Antarctica
 
[15] Austria
 
[19] Bangladesh
 
[22] Belgium
 
[24] Benin
 
[26] Bhutan
 
[28] Bosnia and Herzegovina
 
[29] Botswana
 
[30] Bouvet Island
 
[32] British Indian Ocean Territory
 
[33] Brunei Darussalam
 
[34] Bulgaria
 
[35] Burkina Faso
 
[36] Burundi
 
[40] Cabo Verde
 
[42] Central African Republic
 
[43] Chad
 
[46] Christmas Island
 
[47] Cocos (Keeling) Islands
 
[49] Comoros
 
[50] Congo
 
[54] Cote d’Ivoire
 
[55] Croatia
 
[56] Cuba
 
[57] Cyprus
 
[58] Czech Republic
 
[59] Denmark
 
[60] Djibouti
 
[61] Dominica
 
[62] Dominican Republic
 
[66] Equatorial Guinea
 
[67] Eritrea
 
[68] Estonia
 
[69] Ethiopia
 
[70] Falkland Islands (Malvinas)
 
[72] Fiji
 
[73] Finland
 
[74] France
 
[78] Gabon
 
[79] Gambia
 
[82] Ghana
 
[84] Greece
 
[85] Greenland
 
[86] Grenada
 
[87] Guadeloupe
 
[91] Guinea
 
[92] Guinea-Bissau
 
[94] Haiti
 
[95] Heard Island and Mc Donald Islands
 
[96] Holy See (Vatican City State)
 
[98] Hong Kong
 
[99] Hungary
 
[103] Iran, Islamic Republic of
 
[104] Iraq
 
[105] Ireland
 
[107] Israel
 
[108] Italy
 
[109] Jamaica
 
[111] Jersey
 
[115] Kosovo
 
[116] Kiribati
 
[117] Korea, Democratic People’s Republic of
 
[118] Korea, Republic of
 
[121] Lao People’s Democratic Republic
 
[122] Latvia
 
[123] Lebanon
 
[125] Liberia
 
[126] Libya
 
[128] Lithuania
 
[129] Luxembourg
 
[131] North Macedonia
 
[132] Madagascar
 
[133] Malawi
 
[136] Mali
 
[137] Malta
 
[139] Martinique
 
[140] Mauritania
 
[144] Micronesia, Federated States of
 
[147] Mongolia
 
[149] Montserrat
 
[151] Mozambique
 
[152] Myanmar
 
[154] Nauru
 
[155] Nepal
 
[156] Netherlands
 
[157] Netherlands Antilles
 
[158] New Caledonia
 
[161] Niger
 
[163] Niue
 
[164] Norfolk Island
 
[165] Northern Mariana Islands
 
[166] Norway
 
[169] Palau
 
[170] Palestine, State of
 
[175] Philippines
 
[176] Pitcairn
 
[177] Poland
 
[178] Portugal
 
[179] Puerto Rico
 
[181] Reunion
 
[184] Rwanda
 
[185] Saint Barthelemy
 
[186] Saint Helena, Ascension and Tristan da Cunha
 
[188] Saint Lucia
 
[189] Saint Martin (French part)
 
[190] Saint Pierre and Miquelon
 
[194] Sao Tome and Principe
 
[196] Senegal
 
[200] Singapore
 
[201] Slovakia
 
[202] Slovenia
 
[203] Solomon Islands
 
[204] Somalia
 
[206] South Georgia and the South Sandwich Islands
 
[207] Spain
 
[209] Sudan
 
[210] Suriname
 
[211] Svalbard and Jan Mayen
 
[212] Eswatini
 
[213] Sweden
 
[214] Switzerland
 
[215] Syrian Arab Republic
 
[217] Tajikistan
 
[220] Timor-Leste
 
[221] Togo
 
[222] Tokelau
 
[223] Tonga
 
[226] Turkey
 
[228] Turks and Caicos Islands
 
[229] Tuvalu
 
[230] Uganda
 
[234] United States
 
[238] Vanuatu
 
[239] Venezuela, Bolivarian Republic of
 
[240] Viet Nam
 
[242] Virgin Islands, U.S.
 
[243] Wallis and Futuna
 
[244] Western Sahara
 
[245] Yemen
 
[246] Zambia
 
[247] Zimbabwe
 
[253] Curaçao
 
[254] Bonaire, Sint Eustatius and Saba
 
[255] South Sudan
 
 

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------|----------------------------------|-----------------------------------------------|
| allow Germany | allows Germany processing | Type: Enum Default: N |
| allow UK | allows United Kingdom processing | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------|
| 10124 | 1134 | MCC 7995 rules violation |

##### CDB processing restrictions

Deny all countries except USA and EU countries. Also deny the foloowing EU countries: Austria, Belgium, Denmark, Malta, Portugal, Romania, Slovakia, Estonia, Latvia; and the following US satates: Alabama, Georgia, Missouri, South Dakota, Nebraska, California, North Carolina, Florida.

Score: No

Enabled by default: N

**Parameters**

| Name | Value |
|----------------------------------------|-----------------------------------------------|
| check credit card BIN country | Type: Enum Default: Y |
| check customer billing address country | Type: Enum Default: Y |
| check customer IP country | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------|
| 10167 | 1177 | CDB processing restrictions violation. |

#### Velocity filters

##### Source Credit Card Number decline frequency for last 24 hours (daily decline limit)

This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card used as Source card | Type: Decimal Default: 999999999 |
| For all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this credit card used as Source card | Type: Int Default: 99999 |
| Use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------|
| 10083 | 1093 | Daily decline amount limit exceeded for sender |
| 10084 | 1094 | Daily decline quantity limit exceeded for sender |

##### Source Credit Card Number increasing sequence of approved transaction amounts for last 24 hours (daily rising limit)

This check fires when the number of approved transactions with increasing amount associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 increasing transactions, it fires on the 11th increasing transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the Approved status. This check only cross-checks transactions within the same merchant account in the same project.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------|-----------------------------------------------------------------------------------------------------|--------------------------------------------------|
| quantity limit | maximum transactions count with increasing amount for the last 24 hours for this credit card number | Type: Int Default: 99999 |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10022 | 1032 | Too many transactions with increasing amounts for sender |

##### Source Credit Card Number usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card used as Source card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this credit card used as Source card | Type: Int Default: 99999 |
| skip payouts | allows to process Payout transactions even when the count or amount exceeds the thresholds | Type: Enum Default: N |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar day | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------|
| 10016 | 1026 | Daily amount limit exceeded for sender |
| 10017 | 1027 | Daily quantity limit exceeded for sender |

##### Source Credit Card Number usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this credit card used as Source card | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this credit card used as Source card | Type: Int Default: 99999 |
| skip payouts | allows to process Payout transactions even when the count or amount exceeds the thresholds | Type: Enum Default: N |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar week | “Y” For calculation using calendar weeks instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------|
| 10018 | 1028 | Weekly amount limit exceeded for sender |
| 10019 | 1029 | Weekly quantity limit exceeded for sender |

##### Source Credit Card Number usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this credit card used as Source card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this credit card used as Source card | Type: Int Default: 99999 |
| skip payouts | allows to process Payout transactions even when the count or amount exceeds the thresholds | Type: Enum Default: N |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar month | “Y” For calculation using calendar months instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------|
| 10020 | 1030 | Monthly amount limit exceeded for sender |
| 10021 | 1031 | Monthly quantity limit exceeded for sender |

##### Destination Credit Card Number usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions only in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this credit card used as Destination card | Type: Int Default: 99999 |
| use calendar day | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------|
| 10049 | 1059 | Daily amount limit exceeded for recipient |
| 10050 | 1060 | Daily quantity limit exceeded for recipient |

##### Destination Credit Card Number usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions only in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this credit card used as Destination card | Type: Decimal Default: 99999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this credit card used as Destination card | Type: Int Default: 99999 |
| use calendar week | “Y” For calculation using calendar weeks instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------|
| 10051 | 1061 | Weekly amount limit exceeded for recipient |
| 10052 | 1062 | Weekly quantity limit exceeded for recipient |

##### Destination Credit Card Number usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions only in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| check preauth transactions | “Y” Prohibit preauth transactions when the quantity limit is reached, it is necessary to enable the filter and set the correct values of the limit on all projects where this functionality requires | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this credit card used as Destination card | Type: Int Default: 99999 |
| Use calendar month | “Y” For calculation using calendar months instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------|
| 10053 | 1063 | Monthly amount limit exceeded for recipient |
| 10054 | 1064 | Monthly quantity limit exceeded for recipient |

##### Total Credit Card Number usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card used as Source or Destination | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this credit card used as Source or Destination | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar day | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------|
| 10055 | 1065 | Daily total amount limit exceeded for sender |
| 10056 | 1066 | Daily total quantity limit exceeded for sender |
| 10057 | 1067 | Daily total amount limit exceeded for recipient |
| 10058 | 1068 | Daily total quantity limit exceeded for recipient |

##### Total Credit Card Number usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this credit card used as Source or Destination | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this credit card used as Source or Destination | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar week | “Y” For calculation using calendar weeks instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------|
| 10059 | 1069 | Weekly total amount limit exceeded for sender |
| 10060 | 1070 | Weekly total quantity limit exceeded for sender |
| 10061 | 1071 | Weekly total amount limit exceeded for recipient |
| 10062 | 1072 | Weekly total quantity limit exceeded for recipient |

##### Total Credit Card Number usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this credit card used as Source or Destination | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this credit card used as Source or Destination | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar month | “Y” For calculation using calendar months instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------|
| 10063 | 1073 | Monthly total amount limit exceeded for sender |
| 10064 | 1074 | Monthly total quantity limit exceeded for sender |
| 10065 | 1075 | Monthly total amount limit exceeded for recipient |
| 10066 | 1076 | Monthly total quantity limit exceeded for recipient |

##### Purpose usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this Purpose | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this Purpose | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------|
| 10040 | 1050 | Daily amount limit exceeded for purpose |
| 10041 | 1051 | Daily quantity limit exceeded for purpose |

##### Purpose usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this Purpose | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this Purpose | Type: Int Default: 99999 |
| Subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: Y |
| Use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------|
| 10042 | 1052 | Weekly amount limit exceeded for purpose |
| 10043 | 1053 | Weekly quantity limit exceeded for purpose |

##### Purpose usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this Purpose | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this Purpose | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------|
| 10044 | 1054 | Monthly amount limit exceeded for purpose |
| 10045 | 1055 | Monthly quantity limit exceeded for purpose |

##### Email usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this Email address | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this Email address | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 10073 | 1083 | Daily amount limit exceeded for email address |
| 10074 | 1084 | Daily quantity limit exceeded for email address |

##### Email usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this Email address | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this Email address | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------|
| 10075 | 1085 | Weekly amount limit exceeded for email address |
| 10076 | 1086 | Weekly quantity limit exceeded for email address |

##### Email usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this Email address | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this Email address | Type: Int Default: 99999 |
| Subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| Use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------|
| 10077 | 1087 | Monthly amount limit exceeded for email address |
| 10078 | 1088 | Monthly quantity limit exceeded for email address |

##### IP address usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact customer IP address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this IP address | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this IP address | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------|
| 10100 | 1110 | Daily amount limit exceeded for IP address |
| 10101 | 1111 | Daily quantity limit exceeded for IP address |

##### IP address usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact customer IP address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this IP address | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this IP address | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------|
| 10102 | 1112 | Weekly amount limit exceeded for IP address |
| 10103 | 1113 | Weekly quantity limit exceeded for IP address |

##### IP address usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact customer IP address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this IP address | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated: - Y: for all projects - 3DS: for 3DS gates only - Non-3DS: for non-3DS gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this IP address | Type: Int Default: 99999 |
| Subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| Use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------|
| 10104 | 1114 | Monthly amount limit exceeded for IP address |
| 10105 | 1115 | Monthly quantity limit exceeded for IP address |

##### Source Credit Card Number usage frequency for Purpose

This check fires when the number of Source Credit Cards associated with exact Purpose exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Account verification, Sale, Preauth or Transfer transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique credit card numbers count | Type: Int Default: 12 |
| maximum card number count | maximum number of unique credit cards | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 10071 | 1081 | Too many credit cards used for the same account |

##### Source Credit Card Number usage frequency for Email address

This check fires when the number of Source Credit Cards associated with exact Email address exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Account verification, Sale, Preauth or Transfer transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique credit card numbers count | Type: Int Default: 12 |
| maximum card number count | maximum number of unique credit cards | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------|
| 10091 | 1101 | Too many credit cards used for the same Email address |

##### Source Credit Card Number usage frequency for First and Last name

This check fires when the number of Source Credit Cards associated with exact Customer First and Last names exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Sale or Preauth transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique credit card numbers count | Type: Int Default: 12 |
| maximum card number count | maximum number of unique credit cards | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------|
| 10092 | 1102 | Too many credit cards used for the same customer |

##### Source Credit Card Number usage frequency for Destination Credit Card number

This check fires when the number of Source Credit Cards associated with exact Destination Credit Card number exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Transfer transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------|-------------------------------------------------------|
| checking interval in hours | time frame to calculate unique credit card numbers count | Type: Decimal Default: 12.000 |
| maximum card number count | maximum number of unique credit cards | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10093 | 1103 | Too many source cards used for the same destination card |

##### Source Credit Card Number usage frequency for Email or IP address

This check fires when the number of Source Credit Cards associated with exact Email or IP address exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Sale, Preauth or Transfer transactions in Approved status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique credit card numbers count | Type: Int Default: 24 |
| maximum card number count | maximum number of unique credit cards | Type: Int Default: 4 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------------|
| 10026 | 1036 | Too many source cards used for the same email or IP address |

##### Source Credit Card Number usage frequency

This check fires when the number of requests associated with exact Source Credit Card exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 requests in 6 hours, it fires on the 11th request in 6 hours. Counts requests count for Account verification, Sale, Preauth or Transfer transactions in the Approved or Declined status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate requests count | Type: Int Default: 24 |
| maximum number of requests | maximum number of requests allowed | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------|
| 10072 | 1082 | Too many requests for the same credit card |

##### Customer IP address usage frequency

This check fires when the number of requests associated with exact Customer IP address exceeds the configured thresholds. Such Customer IP address is automatically added to the IP blacklist of merchant and manager. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 requests in 60 minutes, it fires on the 11th request in 60 minutes. Counts requests count for Account verification, Sale, Preauth or Transfer transactions in the Approved or Declined status for the current Merchant. Local IP addresses are ignored. Requests from IP address listed in “Merchant API IP address” list are ignored, i.e. if merchant initiates the request from IP address X.X.X.X and knowingly sets customer_ip_address to Y.Y.Y.Y for each transaction, but address X.X.X.X classified as “API IP address” for this merchant, this check will be ignored.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to calculate requests count | Type: Int Default: 10 |
| maximum number of requests | maximum number of requests allowed | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------|
| 10115 | 1125 | Too many requests from the same IP address |

##### Credit Card number already used from another IP address

This check fires when the Credit Card number has already been successfully used from a different IP address. The time threshold is a moving window calculated backwards from the moment of the transaction. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes, set to 0 for infinity (not recommended) | Type: Int Default: 30 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------|
| 10008 | 1006 | Too many IP addresses for the same credit card number |

##### Credit Card number already used from another Country

This check fires when the Credit Card number has already been successfully used from another Country. IP address is used to calculate customers country code. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------|
| 10079 | 1089 | Too many countries for the same credit card number |

##### Credit Card number already used with another Email

This check fires when the Credit Card number has already been successfully used with a different Email address. The time threshold is a moving window calculated backwards from the moment of the transaction. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes, set to 0 for infinity (not recommended) | Type: Int Default: 30 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 10007 | 1005 | Too many Emails for the same credit card number |

##### Credit Card number already used with another Purpose

This check fires when the Credit Card number has already been successfully used with a different Purpose. The time threshold is a moving window calculated backwards from the moment of the transaction. This check only cross-checks transactions within the same merchant account. Analyses Account verification, Sale, Preauth or Transfer transactions in the Approved status. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes, set to 0 for infinity (not recommended) | Type: Int Default: 30 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------|
| 10081 | 1091 | Too many purposes for the same credit card number |

##### Credit Card number already used with another Cardholder name

This check fires when the Credit Card number has already been successfully used with another Cardholder name. Distances between current Cardholder name and existing ones are calculated using Levenshtein algorithm. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|-------------------------------|-----------------------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to analyse approved transactions in hours | Type: Int Default: 30 |
| greatest levenshtein distance | greatest levenshtein distance to consider both cardholder names equal | Type: Int Default: 3 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10089 | 1099 | Too many cardholder names for the same credit card number |

##### Customer IP address already used by another Cardholder

This check fires when the Customer IP address has already been successfully used by a customer with a different Cardholder name. The time threshold is a moving window calculated backwards from the moment of the transaction. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes | Type: Int Default: 30 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------|
| 10006 | 1004 | Too many card holders from the same IP address |

##### Customer Email already used by another Cardholder

This check fires when the Customer Email has already been successfully used by a customer with a different Cardholder name. The time threshold is a moving window calculated backwards from the moment of the transaction. This check only cross-checks transactions within the same merchant account. Analyses Sale, Preauth or Transfer transactions in the Approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes | Type: Int Default: 30 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------|
| 10005 | 1003 | Too many card holders for the same Email |

##### Source Credit Card Number approved transaction interval

This check fires when the interval for the last approved transaction associated with exact Source credit card number lesser the configured thresholds. The time threshold is time window calculated backwards from the moment of the transaction. The risk fires on the transaction below the set threshold. So, if you set a threshold of 10 minutes and the last approved transaction time is 10:00:00, it fires untill 10:10:01. Counts Sale, Preauth or Transfer transactions in the Approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes | Type: Int Default: 30 |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------------|
| 10023 | 1033 | Too many approved transactions for the same credit card number |

##### Source Credit Card Number declined transaction interval

This check fires when the interval for the last declined transaction associated with exact Source credit card number lesser the configured thresholds. The time threshold is time window calculated backwards from the moment of the transaction. The risk fires on the transaction below the set threshold. So, if you set a threshold of 10 minutes and the last declined transaction time is 10:00:00, it fires untill 10:10:01. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined and Filtered status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in minutes | time frame to analyse approved transactions in minutes | Type: Int Default: 30 |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------------|
| 10085 | 1095 | Too many declined transactions for the same credit card number |

##### Source Credit Card Number Issuer Country change frequency for current Purpose

This check fires when the number of Countries, calculated for Source Credit Card number issuer, associated with exact Purpose exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 Countries in 24 hours, it fires on the 3rd unique Country in 24 hours for the same Purpose. Counts unique Source Credit Card number issuer Countries for Sale, Preauth or Transfer transactions in Approved status for the current Merchant. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|-----------------------------------------------------|---------------------------------------------------|
| checking interval in hours | time frame to calculate countries count | Type: Int Default: 24 |
| ignore BINs | requests for listed BINs are ignoring this check | Type: String Default: N/A |
| maximum countries count | maximum number of countries per one purpose allowed | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------|
| 10122 | 1132 | Too many countries per account |

##### Reversal frequency

This check fires when the number or ratio of reversal transactions calculated for the whole merchant or for the exact merchant project exceeds the configured thresholds. Ratio is calculated for the full lifetime, absolute number could be limited for the whole lifetime or on daily basis from 00:00:00 till 23:59:59. The risk fires on the transaction after the set threshold. So, if you set a threshold of 5 reversals, it fires on the 6th one. Ratio calculation is based on transitions count, i.e. total reversal transactions count divided by total sale transactions count. Counts Sale and Capture transactions in Approved status and Reversal and Void transactions.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|---------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------|
| absolute number | maximum allowable number of reversal transactions | Type: Int Default: 99999 |
| daily absolute number | maximum allowable number of reversal transactions per day | Type: Int Default: 9999 |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: N |
| percentage ratio | maximum allowable ratio of reversal transactions calculated by transaction count in percent (from 0 to 100) | Type: Decimal Default: 101.000 |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------|
| 10036 | 1046 | Too high reversal ratio |
| 10037 | 1047 | Too many reversals |
| 10038 | 1048 | Too many reversals today |

##### Fingerprint usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this Fingerprint | Type: Decimal Default: 999999999 |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this Fingerprint | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------|
| 10170 | 1180 | Daily amount limit exceeded for fingerprint |
| 10171 | 1181 | Daily quantity limit exceeded for fingerprint |

##### Fingerprint usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this Fingerprint | Type: Decimal Default: 99999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this credit Fingerprint | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------|
| 10172 | 1182 | Weekly amount limit exceeded for fingerprint |
| 10173 | 1183 | Weekly quantity limit exceeded for fingerprint |

##### Fingerprint usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this Fingerprint | Type: Decimal Default: 999999999 |
| for all merchant projects | Y - to check transactions for all projects of the current merchant, otherwise check transactions for current project only | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this credit Fingerprint | Type: Int Default: 99999 |
| subtract Cancel transactions | subtracts Cancelled transactions from the calculated count and amount thresholds | Type: Enum Default: N |
| use calendar days | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 10174 | 1184 | Monthly amount limit exceeded for fingerprint |
| 10175 | 1185 | Monthly quantity limit exceeded for fingerprint |

##### Source Credit Card Number usage frequency for Fingerprint

This check fires when the number of Source Credit Cards associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Source Credit Card numbers for Account verification, Sale, Preauth or Transfer transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|--------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique card number count | Type: Int Default: 12 |
| maximum card count | maximum number of unique card numbers | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------|
| 10176 | 1186 | Too many source credit cards used for the same fingerprint |

##### Source Credit Card number Issuer Country change frequency for current Device Fingerprint

This check fires when the number of Countries, calculated for Source Credit Card number issuer, associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 Countries in 24 hours, it fires on the 3rd unique Country in 24 hours for the same Purpose. Counts unique Source Credit Card number issuer Countries for Sale, Preauth or Transfer transactions in Approved status for the current Merchant. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|--------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique card number count | Type: Int Default: 24 |
| maximum countries count | maximum number of countries for one fingerprint | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------|
| 10177 | 1187 | Too many countries for the same fingerprint |

##### Destination Credit Card Number usage frequency for Device fingerprint

This check fires when the number of Destination Credit Cards associated with exact Device Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards in 6 hours, it fires on the 11th unique Credit Card in 6 hours. Counts unique Destination Credit Card numbers for Transfer transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique destination credit card numbers count | Type: Int Default: 12 |
| maximum card count | maximum number of unique destination credit cards | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------------|
| 10178 | 1188 | Too many destination credit cards used for the same fingerprint |

##### Destination Credit Card number Issuer Country change frequency for current Device fingerprint

This check fires when the number of Countries, calculated for Destination Credit Card number issuer, associated with exact Device Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 Countries in 24 hours, it fires on the 3rd unique Country in 24 hours for the same Fingerprint. Counts unique Destination Credit Card number issuer Countries for Sale, Preauth or Transfer transactions in Approved status for the current Merchant. Requests from IP addresses listed in “Merchant API IP address” are ignoring this check.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|-------------------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique card number count | Type: Int Default: 24 |
| maximum countries count | maximum number of destination countries for one fingerprint | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------------------|
| 10179 | 1189 | Too many destination credit cards countries used for the same fingerprint |

##### Email usage frequency for Device fingerprint

This check fires when the number of email addresses associated with exact Device Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 email addresses in 24 hours, it fires on the 3rd unique email address in 24 hours for the same Fingerprint. Counts unique email addresses for all types of transactions for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique emails count | Type: Int Default: 24 |
| maximum emails count | maximum number of emails for one fingerprint | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------|
| 10180 | 1190 | Too many emails used for the same fingerprint |

##### Purpose usage frequency for Device fingerprint

This check fires when the number of Purpose associated with exact Device Fingerprint exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 2 Purpose in 24 hours, it fires on the 3rd unique Purpose in 24 hours for the same Fingerprint. Counts unique Purposes for all types of transactions for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|------------------------------------------------|-----------------------------------------------|
| checking interval in hours | time frame to calculate unique purposes count | Type: Int Default: 24 |
| maximum purposes count | maximum number of purposes for one fingerprint | Type: Int Default: 5 |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------|
| 10181 | 1191 | Too many purposes used for the same fingerprint |

##### Account Number usage frequency for last 24 hours (daily limit)

This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this account number | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last 24 hours for this credit card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 24 hours for this account number | Type: Int Default: 99999999 |
| skip payouts | ignore payouts | Type: Enum Default: N |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |
| use calendar day | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10187 | 1197 | Daily amount limit exceeded for account number address |
| 10188 | 1198 | Daily quantity limit exceeded for account number address |

##### Account Number usage frequency for last 7 days (weekly limit)

This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this account number | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last 7 days for this account number calculated | Type: Int Default: 99999999 |
| skip payouts | ignore payouts | Type: Enum Default: N |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |
| use calendar week | “Y” For calculation using calendar week instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10189 | 1199 | Weekly amount limit exceeded for account number address |
| 10190 | 1200 | Weekly quantity limit exceeded for account number address |

##### Account Number usage frequency for last month (monthly limit)

This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last one month for this account number | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last one month for this credit card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last one month for this account number | Type: Int Default: 99999999 |
| skip payouts | ignore payouts | Type: Enum Default: N |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |
| use calendar month | “Y” For calculation using calendar month instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------|
| 10191 | 1201 | Monthly amount limit exceeded for account number address |
| 10192 | 1202 | Monthly quantity limit exceeded for account number address |

##### Preventing transaction with the same amount

This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-----------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| checking interval in seconds | max interval in seconds to check requests with the same amount, values more then 300 seconds or less 10 seconds are ignored | Type: int Default: 60 |
| skip declined transactions | Y - to skip sessions in Filtered or Declined status, N - otherwise | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------------------------|
| 10198 | 1208 | Such transaction amount has already been processed in the set threshold of time |

##### Issuer country usage frequency

This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| Checking interval in seconds | max interval in seconds to check transactions associated with the same card issuer country, values more then 300 seconds or less 10 seconds are ignored | Type: int Default: 60 |
| Quantity limit | pick a value for the number of transactions over which the filter will be fired | Type: int Default: 10 |
| Skip country identifier | choose the countries where the filter will be applied | Type: List Default: \* |
| Skip declined transactions | Y - to skip sessions in Filtered or Declined status, N - otherwise | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------|
| 10199 | 1209 | Exceeding the limit of cards issued in the same country |

##### Purpose usage frequency for last year (annual limit)

This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one year window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 100 transactions, it fires on the 101th transaction in one year. Calculation of the year can be started from the beginning of the calendar year or from the filter activation truncated to the month and -12 months. I.e. if you activated the filter on May 15, 2021, the filter will consider transactions from May 2020. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------|
| amount limit | maximum total transactions amount for the last year for this Purpose | Type: int Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last year for this Purpose value would be calculated. - Y: for all projects. - 3D: for 3D gates only. - Non3D: for non 3D gates only. N: for current project only of the current merchant and converted to current project currency to compare with amount or quantity limit values | Type: Enum Default: Y |
| quantity limit | maximum total transactions count for the last year for this Purpose | Type: int Default: 99999 |
| subtract Cancel transactions | \* | Type: Enum Default: N |
| use calendar year | \* | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------|
| 10200 | 1210 | Annual amount limit exceeded for purpose |
| 10201 | 1211 | Annual quantity limit exceeded for purpose |

##### BIN range usage frequency

This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------|
| BIN range exceptions | card BIN range list for which checks will not be performed | Type: \* Default: \* |
| checking interval in seconds | max interval in seconds to check transactions associated with the same card issuer country, values more then 300 seconds or less 10 seconds are ignored | Type: int Default: 60 |
| quantity limit | pick a value for the number of transactions over which the filter will be fired | Type: int Default: 10 |
| skip declined transactions | Y - to skip sessions in Filtered or Declined status, N - otherwise | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------------------|
| 10202 | 1212 | Exceeding the limit of cards associated with the same card BIN range |

##### Abnormal transaction time

This check fires when transactions are received outside the set time period. So, if you set the time period from 10:00 to 20:00, it fires on any transaction from 0:00 to 9:59 and from 20:00 to 0:00. The time is set in the GMT+3 time zone. Counts Sale, Preauth, Payouts or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Value |
|------------------|-----------------------------------------------------|
| Time period from | Type: String Default: 10:00 |
| Time period to | Type: String Default: 19:00 |
| Time zone | Type: Int Default: 3 |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------------------------------|
| 10203 | 1213 | Transaction in abnormal time |
| 10204 | 1214 | Customer data validation failed (first name, last name, cardholder, email, phone) |

##### Source Credit Card Number decline frequency for last week (weekly decline limit)

This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 7 days for this credit card used as Source card | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last 7 days for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last 7 days for this credit card used as Source card | Type: Int Default: 99999 |
| use calendar week | “Y” For calculation using calendar week instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------|
| 10206 | 1216 | Weekly decline amount limit exceeded for sender |
| 10207 | 1217 | Weekly decline quantity limit exceeded for sender |

##### Source Credit Card Number usage frequency per Email address for last 24 hours (daily limit)

This check fires when the number of Source Credit Cards associated with exact Email address exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction.
The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards, it fires on the 11th unique Credit Card in 24 hours.
Counts unique Source Credit Card numbers for Sale or Preauth transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| approved only | counts unique Source Credit Card numbers for Sale or Preauth transactions in approved status | Type: Enum Default: N |
| maximum card number count | maximum total card number count for the last 24 hours for this Email address | Type: Int Default: 99999 |
| use calendar day | “Y” For calculation using calendar days instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10208 | 1218 | Daily card number count limit exceeded for email address |

##### Source Credit Card Number usage frequency per Email address for last 7 days (weekly limit)

This check fires when the number of Source Credit Cards associated with exact Email address exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction.
The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards, it fires on the 11th unique Credit Card in 7 days.
Counts unique Source Credit Card numbers for Sale or Preauth transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| approved only | counts unique Source Credit Card numbers for Sale or Preauth transactions in approved status | Type: Enum Default: N |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| maximum card number count | maximum total card number count for the last 7 days for this Email address | Type: Int Default: 99999 |
| use calendar week | “Y” For calculation using calendar week instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10209 | 1219 | Weekly card number count limit exceeded for email address |

##### Source Credit Card Number usage frequency per Email address for last month (monthly limit)

This check fires when the number of Source Credit Cards associated with exact Email address exceeds the configured thresholds. The time threshold is a moving window calculated backwards from the moment of the transaction.
The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 Credit Cards, it fires on the 11th unique Credit Card in 1 month.
Counts unique Source Credit Card numbers for Sale or Preauth transactions in any status for the current Merchant.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| approved only | counts unique Source Credit Card numbers for Sale or Preauth transactions in approved status | Type: Enum Default: N |
| maximum card number count | maximum total card number count for the last month for this Email address | Type: Int Default: 99999 |
| use calendar month | “Y” For calculation using calendar month instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------|
| 10210 | 1220 | Monthly card number count limit exceeded for email address |

##### Source Credit Card Number usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this credit card used as Source card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this credit card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this credit card used as Source card | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------|
| 10211 | 1221 | Specified period amount limit exceeded for sender |
| 10212 | 1222 | Specified period quantity limit exceeded for sender |

##### Destination Credit Card Number usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this Destination card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this credit card used as Destination card | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------------|
| 10213 | 1223 | Specified period amount limit exceeded for recipient |
| 10214 | 1224 | Specified period quantity limit exceeded for recipient |

##### Total Credit Card Number usage frequency for last N days

This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this credit card used as Source or Destination card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this credit card value would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this credit card used as Source or Destination card | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------------------------------|
| 10215 | 1225 | Specified period total amount limit exceeded for sender |
| 10216 | 1226 | Specified period total quantity limit exceeded for sender |
| 10217 | 1227 | Specified period total amount limit exceeded for recipient |
| 10218 | 1228 | Specified period total quantity limit exceeded for recipient |

##### Purpose usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this Purpose | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this Purpose would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this Purpose | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------|
| 10219 | 1229 | Specified period amount limit exceeded for purpose |
| 10220 | 1230 | Specified period quantity limit exceeded for purpose |

##### Email usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Email exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this Email | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this Email would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this Email | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------|
| 10221 | 1231 | Specified period amount limit exceeded for email address |
| 10222 | 1232 | Specified period quantity limit exceeded for email address |

##### IP address usage frequency for last N days

This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this IP address | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this IP address would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this IP address | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------|
| 10223 | 1233 | Specified period amount limit exceeded for IP address |
| 10224 | 1234 | Specified period quantity limit exceeded for IP address |

##### Fingerprint usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this Fingerprint | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this Fingerprint would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this Fingerprint | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------------|
| 10225 | 1235 | Specified period amount limit exceeded for fingerprint |
| 10226 | 1236 | Specified period quantity limit exceeded for fingerprint |

##### Account Number usage frequency for last N days

This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth, Payout or Transfer transactions in the approved status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last N days for this Account Number | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last N days for this Account Number would be calculated Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| for last N days | date period can be set from 1 to 30 days | Type: Int Default: 1 |
| quantity limit | maximum total transactions count for the last N days for this Account Number | Type: Int Default: 99999 |
| subtract Cancel transactions | ignore cancel transactions for two-stage payments | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------------|
| 10227 | 1237 | Specified period amount limit exceeded for account number |
| 10228 | 1238 | Specified period quantity limit exceeded for account number |

##### Source Credit Card Number decline frequency for last month (monthly decline limit)

This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last month for this credit card used as Source card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last month for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last month for this credit card used as Source card | Type: Int Default: 99999 |
| use calendar month | “Y” For calculation using calendar month instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------------------------|
| 10229 | 1239 | Monthly decline amount limit exceeded for sender |
| 10230 | 1240 | Monthly decline quantity limit exceeded for sender |

##### Destination Credit Card Number decline frequency for last 24 hours (daily decline limit)

This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last day for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last day for this credit card used as Destination card | Type: Int Default: 99999 |
| use calendar day | “Y” For calculation using calendar day instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------|
| 10231 | 1241 | Daily decline amount limit exceeded for recipient |
| 10232 | 1242 | Daily decline quantity limit exceeded for recipient |

##### Destination Credit Card Number decline frequency for last week (weekly decline limit)

This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last week for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last week for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last week for this credit card used as Destination card | Type: Int Default: 99999 |
| use calendar week | “Y” For calculation using calendar week instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------|
| 10233 | 1243 | Weekly decline amount limit exceeded for recipient |
| 10234 | 1244 | Weekly decline quantity limit exceeded for recipient |

##### Destination Credit Card Number decline frequency for last month (monthly decline limit)

This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last month for this credit card used as Destination card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last month for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last month for this credit card used as Destination card | Type: Int Default: 99999 |
| use calendar month | “Y” For calculation using calendar month instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------|
| 10235 | 1245 | Monthly decline amount limit exceeded for recipient |
| 10236 | 1246 | Monthly decline quantity limit exceeded for recipient |

##### Total Credit Card Number decline frequency for last 24 hours (daily decline limit)

This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last 24 hours for this credit card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last day for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last day for this credit card | Type: Int Default: 99999 |
| use calendar day | “Y” For calculation using calendar day instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------|
| 10237 | 1247 | Daily decline total amount limit exceeded for sender |
| 10238 | 1248 | Daily decline total quantity limit exceeded for sender |
| 10239 | 1249 | Daily decline total amount limit exceeded for recipient |
| 10240 | 1250 | Daily decline total quantity limit exceeded for recipient |

##### Total Credit Card Number decline frequency for last week (weekly decline limit)

This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last week for this credit card | Type: Decimal Default: 999999999 |
| calendar week starts from Sunday | “Y”: calendar week starts from Sunday, “N”: calendar week starts from Monday | Type: Enum Default: N |
| for all merchant projects | current total transactions amount or count for the last week for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last week for this credit card | Type: Int Default: 99999 |
| use calendar week | “Y” For calculation using calendar week instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------|
| 10241 | 1251 | Weekly decline total amount limit exceeded for sender |
| 10242 | 1252 | Weekly decline total quantity limit exceeded for sender |
| 10243 | 1253 | Weekly decline total amount limit exceeded for recipient |
| 10244 | 1254 | Weekly decline total quantity limit exceeded for recipient |

##### Total Credit Card Number decline frequency for last month (monthly decline limit)

This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------|
| amount limit | maximum total transactions amount for the last month for this credit card | Type: Decimal Default: 999999999 |
| for all merchant projects | current total transactions amount or count for the last month for this credit card would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: N |
| quantity limit | maximum total transactions count for the last month for this credit card | Type: Int Default: 99999 |
| use calendar month | “Y” For calculation using calendar month instead of calculation from moment when filter was enabled “N” for calculation from moment when filter was enabled | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------------|
| 10245 | 1255 | Monthly decline total amount limit exceeded for sender |
| 10246 | 1256 | Monthly decline total quantity limit exceeded for sender |
| 10247 | 1257 | Monthly decline total amount limit exceeded for recipient |
| 10248 | 1258 | Monthly decline total quantity limit exceeded for recipient |

##### Customer IP address anonymous VPN

This check fires when customer IP address is considered as anonymous VPN by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------|
| 10250 | 1260 | Customer IP address is anonymous VPN |

##### Customer IP address anonymous

This check fires when customer IP address is considered as anonymous by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|----------------------------------|
| 10251 | 1261 | Customer IP address is anonymous |

##### Customer IP Hosting Provider

This check fires when customer IP address belongs to a hosting or VPN provider considered by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------|
| 10252 | 1262 | Customer ip address is hosting provider |

##### Customer IP Public Proxy

This check fires when customer IP address belongs to a public proxy considered by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------|
| 10253 | 1263 | Customer IP address is public proxy |

##### Customer IP Residential Proxy

This check fires when customer IP address belongs to a hosting or VPN provider considered by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------|
| 10254 | 1264 | Customer IP address is residential proxy |

##### Customer IP Tor Exit Node

This check fires when customer IP address is a Tor exit node considered by Max Mind service. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|-------------------------------------------------------------------------------------------------|-----------------------------------------------|
| filter parameter value | Y - to filter if condition is true, N - to filter if condition is false | Type: Enum Default: Y |

**Error codes**

| # | Code | Name |
|-------|--------|--------------------------------------|
| 10255 | 1265 | Customer IP address is tor exit node |

##### Customer static IP score

This check fires when customer IP address static IP score which is considered by Max Mind service is lower or equal to the settled threshold value. Higher values meaning a greater static association. For example, many IP addresses with a user type of cellular have a score under one. Broadband IPs that don’t change very often typically have a score above thirty. This indicator can be useful for deciding whether an IP address represents the same user over time. The value ranges from 0 to 99.99. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|--------------------------------------------|-------------------------------------------------------|
| filter threshold value | Lower or equal values will be filtered out | Type: Decimal Default: 20.000 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------------------------|
| 10256 | 1266 | Customer IP address static IP score is less or equal to configured threshold |

##### Customer IP user count

This check fires when customer IP address user count considered by Max Mind service is higher or equal to the settled threshold value. The estimated number of users sharing the IP/network during the past 24 hours. For IPv4, the count is for the individual IP. For IPv6, the count is for the /64 network. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------|---------------------------------------------|----------------------------------------------|
| filter threshold value | Higher or equal values will be filtered out | Type: Int Default: 3 |

**Error codes**

| # | Code | Name |
|-------|--------|---------------------------------------------------------------------------|
| 10257 | 1267 | Customer IP address user count is higher or equal to configured threshold |

##### Customer IP user type

This check fires when customer IP address user type considered by Max Mind service is in blocked user types list. Possible values: business, cafe, cellular, college, consumer_privacy_network, content_delivery_network, government, hosting, library, military, residential, router, school, search_engine_spider, traveler. Counts Sale, Preauth or Transfer transactions.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|--------------------|------------------------------------------------------------------|----------------------------------------------------|
| blocked user types | Blocked user types will be filtered out, split values with comma | Type: String Default: None |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------------------------------------------|
| 10258 | 1268 | Customer IP address user type is in blocked user types list |

##### Credit Card Number usage frequency for last N hours

This check fires when the number of transactions associated with exact credit card number exceeds the configured thresholds. The time threshold is a N hours window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 24. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N hours. This filter takes into account full hours. Counts Sale, Preauth or Transfer transactions in the approved status. Source and destination cards are considered separately.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|------------------------------------------------------------|-----------------------------------------------|
| for last N hours | time frame to calculate unique credit card count | Type: Int Default: 24 |
| maximum transactions count | maximum number of transactions for one credit card number | Type: Int Default: 2 |
| skip declined transactions | “Y” to skip sessions in Declined status, “N” for otherwise | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------|
| 10269 | 1280 | Specified period quantity limit exceeded |

##### Preventing transaction with the same amount 24 hours

This check fires when the number of transactions with the same amount associated with exact credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Also you can set the value of the amount starting from which transactions will be taken into account by the filter. Counts Sale, Preauth or Transfer transactions in the approved status. Source and destination cards are considered separately.

Score: Yes

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|----------------------------------------------------------------------------------------------------------|----------------------------------------------------|
| maximum transactions count | maximum number of transactions with the same amount | Type: Int Default: 2 |
| min amount to filter | value of the transaction amount starting from which transaction will be taken info account by the filter | Type: Float Default: 0.000 |
| skip declined transactions | “Y” to skip sessions in Declined status, “N” for otherwise | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------------------------------------------|
| 10270 | 1281 | Limit transactions with the same amount for exact card exceeded |

##### Customer Email declined transaction interval

This check fires when the interval for the last declined transaction associated with exact customer email lesser the configured thresholds. The time threshold is time window calculated backwards from the moment of the transaction. The risk fires on the transaction below the set threshold. So, if you set a threshold of 10 minutes and the last declined transaction time is 10:00:00, it fires untill 10:10:01. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------|
| Checking interval in minutes | max interval in minutes to check declines for this email | Type: Int Default: 30 |
| For all merchant projects | Y - to check transactions for all projects of the current merchant N - check transactions for current project only | Type: Enum Default: No |

**Error codes**

| # | Code | Name |
|-------|--------|-------------------------|
| 10274 | 1285 | Decline interval exceed |

##### Customer email decline frequency for last 24 hours (daily decline limit)

This check fires when the number or amount of declined transactions associated with exact customer email exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|---------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------|
| Amount limit | maximum total transactions amount for the last 24 hours for this customer email | Type: Int Default: 99999999 |
| For all merchant projects | current total declines for the last 24 hours for this email would be calculated - Y: for all projects - 3D: for 3D gates only - Non3D: for non 3D gates only - N: for current project only of the current merchant and converted to current project currency to compare with amount limit values | Type: Enum Default: Yes |
| Quantity limit | maximum total transactions count for the last 24 hours for this customer email | Type: Int Default: 99999 |
| use calendar day | Y - For calculation using calendar days instead of calculation from moment when filter check is triggered N - for calculation from moment when filter check is triggered | Type: Enum Default: N |

**Error codes**

| # | Code | Name |
|-------|--------|-----------------------------|
| 10275 | 1286 | Daily amount limit exceed |
| 10276 | 1287 | Daily quantity limit exceed |

##### Customer email usage frequency for last N hours

This check fires when the number of transactions associated with exact customer email exceeds the configured thresholds.
The time threshold is a N hours window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 24. For window calculation all transaction dates are truncated to hours.
The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N hours. This filter takes into account full hours. Counts Sale, Preauth or Transfer transactions in the approved and declined status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|--------------------------------------------------------------------------------|------------------------------------------------|
| for last N hours | time frame to calculate unique customer email count | Type: Int Default: 24 |
| maximum transactions count | maximum number of transactions for one customer email | Type: Int Default: 2 |
| skip declined transactions | Y - to skip sessions in Declined status N - otherwise | Type: Enum Default: No |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------|
| 10277 | 1288 | Specified period quantity limit exceeded |

##### Customer email declines frequency for last N hours

This check fires when the number of declines associated with exact customer email exceeds the configured thresholds.
The time threshold is a N hours window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 24. For window calculation all transaction dates are truncated to hours.
The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N hours. This filter takes into account full hours. Counts Sale, Preauth or Transfer transactions in the declined status.

Score: No

Enabled by default: N

**Parameters**

| Name | Description | Value |
|----------------------------|-------------------------------------------------------|-----------------------------------------------|
| for last N hours | time frame to calculate unique customer email count | Type: Int Default: 24 |
| maximum transactions count | maximum number of transactions for one customer email | Type: Int Default: 2 |

**Error codes**

| # | Code | Name |
|-------|--------|------------------------------------------------------------------------------|
| 10278 | 1289 | Specified period decline quantity limit exceeded for the same customer email |

### Fx Rate

#### Introduction

Fx Rate is a service that allows to receive exchange rates from various Providers.

#### Fx Rate Setup

The screen is located in “Tools” – “Fx Rate” section.

There are two sections in Fx Rate:
: - Terminals
 - Providers

 
`fxrate setup`
 
`fxrate setup`
 
Terminals section shows all available Terminals and adjust their settings.
 
Providers section shows all available Providers and allows to add new Terminal to any Provider.
 
 

> **Note:** To add new Provider, contact the Payneteasy support service.

 
To create a new Terminal for Provider, click the “+ Add terminal” button. New window with parameters will appear as shown below:
 
 
`fxrate setup`
 
In opened window it is possible to:
 
- Name the Terminal
- Select the available Provider from the list
- Choose between two rate types: Buy or Sell
- Choose from which currency to which currency the conversion will be applied
- Add coefficient (additional % modifier to conversion rate)
- Add absolute value (which will be added after every conversion to the resulting amount)
- Add Terminal description

After creating new Terminal it will be possible to see it in “Terminals” section.
 
It is possible to remove or edit Terminal anytime. It is not possible to edit all fields of the already existing Terminal. To edit Terminal settings, click three dots as shown below:
 
 
`fxrate setup`
 
These are all fields that can be changed:
 
 
`fxrate setup`

### Gate Details Report

Displays the amount of successful transactions in the context of gates.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Gate

**Gate Overview**
 
Gate is a set of parameters, which identify account registered in a third-party processing system. These parameters can be used to process payment data in an external system using the messaging protocol implemented in the Processor. The Gate list screen is located at Settings -> Configuration -> Gates. This screen contains all Gates created for Manager in the system.
 
 
`gatesearch manager faq`
 
- Gate is enabled.
 
- Gate is disabled.
 
 
To add new search filters, click the Add filter button. Gates search can be filtered by: Status, Currency, 3D, Endpoint, Merchant, Processor, Project, Reseller and Company.
 
 
`gatefilter manager faq`
 
To monitor the Gate activity, Key Performance Indicators (KPI) are used, such as: Manager earnings, Average order value, and others. The KPI submenu opens by pressing the Detailed button on the Gate search screen. See details in [KPIs Detailed View](https://doc.payneteasy.com/manager/reference/kpi.html.md).
 
Click on the Gate name to open detailed information about this gate.
 
The Gate can only be added to the Project with same currency.
 
To work with other configuration options, see the information below.
 

> **Note:** It is important to note that the Gate settings (such as limits, rates, client definition, etc) override the Processor settings.

**Gate Settings**
 

| [Create, Clone, Edit Gate](https://doc.payneteasy.com/manager/gate/gatecreate.html.md) | This screen shows how to create and edit the gate. |
|--------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------|
| [Gate Details](https://doc.payneteasy.com/manager/gate/gatedetails.html.md) | This screen shows all parameters and details about the gate. |
| [Acquirer Restrictions](https://doc.payneteasy.com/manager/gate/acquirerrestrictions.html.md) | Configurable sets of rules which allow to restrict the traffic by certain criteria (Gate and Processor levels). |
| [Chain Strategy Details](https://doc.payneteasy.com/manager/gate/chainstrategydetails.html.md) | All information about additional cascading chains setup. |
| [Chain Strategy Skips](https://doc.payneteasy.com/manager/gate/chainstrategyskips.html.md) | All information about additional cascading chains setup. |
| [Close Day](https://doc.payneteasy.com/manager/gate/closeday.html.md) | Shows information about close day procedure. |
| [Batch Operations for Gates](https://doc.payneteasy.com/manager/gate/batch_operations.html.md) | This screen shows how to make batch operations with gates. |

### Create, Clone, Edit Gate

#### Gate Creation

 
To create gate, go to Settings -> Configuration -> Gates and press + New Gate in the top right corner.
 
See [Gate details](https://doc.payneteasy.com/manager/gatedetails.html.md) table to correctly specify the configuration for new gate.
 

#### Gate Editing And Cloning

 
Press Edit button to edit the gate or Clone button to clone it.
 
 

 

Gates are cloned for the same processor. The required parameters for new gate are its name and currency.
 
Other gate settings will be inherited automatically. In order to reset parameters to default, select Reset to default.
 
In order to see which changes for new gate will be cloned, press changes button.
 
For cloning/creating several gates at once, click Add button. It is also possible to auto-name new gates by clicking Auto-name.
 
 

 
To clone acquirer restrictions to new gate, click Clone filters.
 
To convert all settings with amount into new currency, click Convert currency Gate settings

### Gate Details

| Parameter Name | Description | Necessity for creation |
|------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------|
| Status | Shows whether gate is enabled or disabled. Can be changed later. | Required |
| 3D | Possible to enable if 3DS flow is expected on this gate. Can be changed later. | Optional |
| Description | Shows gate description. Can be changed later. | Optional |
| MID | Shows Merchant identification number. Can be changed later. | Optional |
| Tags | Shows the tags for this gate. While searching gates by tag, all gates with the same tag will be shown. Can be changed later. | Optional |
| Processor | Shows to which exact processor this gate is linked. CANNOT be changed later. | Required |
| Manager | Shows to which exact manager this gate is linked. CANNOT be changed later. | Required |
| Bank rate plan | Shows which rate plan for acquirer bank is currently specified on the gate. Can be changed later. | Required |
| Dealer | Shows which Dealer is specified on this gate. It is only possible to choose Dealers that are linked to the Processor. CANNOT be changed later. | Required for Processors with Dealers |
| Dealer rate plan | Shows which rate plan for Dealer is currently on the gate. Can be changed later. | Required for Processors with Dealers |
| Company | Shows company to which this gate is related to. Can be changed later. | Optional |
| Loyalty service | Shows which external loyalty service is selected. Can be changed later. | Optional |
| Close day automatically | Provides the option to setup time for automatic close day procedure. Can be changed later. | Optional |
| Use external form | Enable if it is expected to use external form logic (redirect to processor). Can be changed later. | Optional |
| Filter by blacklist | Enable if filtering by blacklist is required. Can be changed later. | Optional |
| API descriptor | Gate descriptor which if set up will be sent in callbacks and status responses to Merchant. Can be changed later. | Optional |
| Min transaction amount | Minimum amount per transaction which is allowed through the gate. Can be changed later. | Optional |
| Max transaction amount | Maximum amount per transaction which is allowed through the gate. Can be changed later. | Optional |
| Method | Additional parameter to group gates by specific marker, if needed. This field is present in transaction report. Can be changed later. | Optional |
| Last day closing date | Shows when the last close day procedure was initiated. | |
| Day closing maximum delay (days) | Select for how many days it is acceptable to delay the close day procedure. Can be changed later. | Optional |
| Automatic selection of day closure | If this parameter is enabled, the system will automatically select the close day procedure time. Can be changed later. | Optional |
| Allow day closing via API | If this parameter is enabled, it will be possible to make “Close day” requests via API. Can be changed later. | Optional |
| Method 2 | Additional parameter to group gates by specific marker, if needed. This field is present in transaction report. Can be changed later. | Optional |
| Financial instrument | For internal use. Can be changed later. | Optional |

### Glossary

For the purposes of this guide, the following terms and their definitions are used:

| Payneteasy Hardware and Software System (Payneteasy Payment Gateway) | An information system designed for automated and secure processing of payment transactions and their storage. |
|------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Payneteasy Payment Management System (Payneteasy UI) | Payment management user interface and analytical platform of Payneteasy Payment Gateway. |
| Merchant | The company that provides services, works or sales of goods through the E-commerce, mobile commerce or mPOS channels. |
| Manager | An organization that provides services for processing transactions of Processor Merchants using the Payneteasy Payment Gateway and accounting for transactions in the Payneteasy UI. |
| Processor | The entity of the system, which is a technical integration with a specific acquiring bank or other payment service provider for processing transactions. |
| Account | Identification data in the Payneteasy UI, which allows the user to interact with the system on their own behalf. |
| Transaction | An agreement to carry out a financial operation between a customer and the merchant to pay for services, work or goods, to return funds for previously paid services, works or goods, to transfer money from card to card, or to hold funds for future payment. |
| Antifraud filter | Technical transaction analysis algorithm for identifying suspicious and fraudulent transactions, based on the experience of Payneteasy employees and international fraud monitoring practices. |
| BIN | Bank identification number, first 6 digits of card number. |

### Guides

### Integration Panel

The screen is located in “Tools” – “Integration Panel” section.
The Integration Panel displays requests sent to the system and system responses to these requests, as well as information about possible errors in the requests. This allows to quickly eliminate errors during integration. The panel also helps to view initiating requests for which, as a result of the error, orders were not created.

The following search criteria are available in Integration Panel:

- by End Point ID or End Point Group ID, to which the request was sent,
- by order ID, assigned to transaction by Payneteasy system,
- by serial number of request and response.

Date range can also be specified for the search.

### KPIs Detailed View

#### Overview

Key Performance Indicators, or KPI, is an analysis module which helps the user to quickly visualize the detailed business related information for each main system entity such as Endpoint, User, Project, Gate and etc..
 

To view the details of the relevant element, open the respective element common screen and pick the KPIs in the dropdown Details menu. The order of KPI shown on the details view corresponds to the order in which KPIs are picked in the dropdown. The first chosen KPI is placed on the left, then goes the second etc. The user can pick up to 5 KPIs.
 
The search criteria (point 1 on the screenshot) only affect the list of elements shown and not the calculated value of the KPI.
 
The KPI value could be calculated within a time period (the control elements 2\` on the picture above). The time period is ignored when the meaning of the KPI contradicts the selected date range or in case the KPI is beside the purpose.
 
Each KPI could be used for sorting to provide the most valuable data. The user can apply the sorting by clicking the name of KPI (the control element 3 on the picture above). Please keep in mind that if KPI is selected for sorting and then removed, the sorting will still be applied.
 

#### KPIs

##### Gross Traffic

Shows: The total sum of the approved transactions of the types: sale, capture, dispute, transfer approved.
 
Update frequency: virtually real-time (no more than 10 seconds delay).
 
Graph: the total sum per hour if selected date range is Today or Yesterday; the total sum per day if selected date range is This Month or previous Month.
 

`grosstraff`

Gross traffic per hour for December 7th.
 

`grosstraff2`

Gross traffic per day for November.
 

##### Earnings

Shows: earnings for the Bank, Dealer, Manager, Reseller or Merchant without holds for any type of transaction in any status
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: the earnings per hour if selected date range is Today or Yesterday; the earnings per day if selected date range is This Month or previous Month.
 

`earing1`

Merchant’s earnings per hour for December 7th.
 

`earing2`

Bank’s earnings per day for November.
 

##### Carryover

Shows: The value of the Carryover for the current date disregarding the selected date range. Each type of user can see respective value of the Carryover. The only exception is a Superior who can see the Carryover for the Manager.
 
Update frequency: daily at 00:00
 
Graph: shows the carryover value staring from the selected date plus 2 months; it shows both total carryover due by the user (positive) and the carryover due to the user (negative). It also shows the carryover balance which is a sum of the two above values.
 

`carryover`

The carryover for the Manager begins from the December 1st. As you can see there’s no carryover from the Bank to the Manager by December 21st and the Merchant’s carryover due is there and thus the carryover balance is negative. Starting from December 22nd the Bank begins paying the carryover to the Manager but they can not cover the Merchant’s carryover. This view allows you to forecast the future carryover dues.
 

##### The Dates Of The First And Last Transactions

Shows: The date of the first and last processed transaction regardless of the date range chosen. It allows quickly finding inactive instances of the infologic model elements.
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: N/A
 

##### Average Transaction Amount

Shows: The average transaction amount: sale, capture, dispute, transfer in approved status. It allows to detect abnormalities when merchant changes the source of incoming payment traffic or the products sold.
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: Minimal, maximal and average transaction amount per hour if selected date range is Today or Yesterday; the Minimal, maximal and average transaction amount per day if selected date range is This Month or previous Month.
 

`average1`

Minimal, maximal and average transaction amount per hour for December 7th
 

`average2`

Minimal, maximal and average transaction amount per day for November
 

##### Order Number Per Client Per Month

Shows: The average number of the transaction of any type and in any status for the month which falls into the selected date range. The KPI is only calculated for Endpoints and Projects. The definition of the customer is set up at the Project level, one card means one customer by default. The customer at the Endpoint differs from the customer at the Project to have an option to examine various sources of the payment traffic
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: the number of orders made by a customer per month ending by the chosen date and starting from the date of 12 months earlier.
 

`order`

The number of orders made by a customer per month. Various numbers of orders are marked by different colors . The customers who made 5-6, 7-10 and more than 10 orders are united into one group.
 

##### The Returning Clients Conversion

Shows: The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer for the month that fall into selected date range. The transaction is considered repeated for the chosen month if the customer has made a transaction at any time before. The KPI is only calculated for Endpoints and Projects. The definition of the customer is set up at the Project level, one card means one customer by default. The customer at the Endpoint differs from the customer at the Project to have an option to examine various sources of the payment traffic
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer per month ending by the chosen date and starting from the date of 12 months earlier.
 

`conversion`

The ratio of the repeated transactions made by a particular customer to the total number of transactions made by the customer per month for the past year.
 

##### Transactions By Country By Client’s IP Address

Shows: The country is determined by the IP address of the customer. The transactions of any type in any status are taken into consideration. The parameter does not depend on the date range and is calculated for the lifetime.
 
Update frequency: daily at 00:45
 
Graph: The number of transactions of any type in any status per country which is derived from the customer’s IP address for the given date range, refreshed every 10 seconds
 

`trans_by_country`

The number of transactions for top 10 countries which are derived from the customer’s IP address
 

##### Transactions By Country By BIN

Shows: The country is derived from the customer’s card BIN. The transactions of any type in any status are taken into consideration. The parameter does not depend on the date range and is calculated for the lifetime.
 
Update frequency: daily at 00:45
 
Graph: The number of transactions of any type in any status per country which is derived from the customer’s card BIN for the given date range, refreshed every 10 seconds
 

`bin_country`

The number of transactions for top 10 countries which are derived from the customer’s card BIN.
 

##### Average Earnings Per Transaction

Shows: Average earnings per transaction for Bank, Dealer, Manager, Reseller or Merchant without holds for any type of transaction in any status.
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: Average earnings per transaction per hour if selected date range is Today or Yesterday; the Average earnings per transaction per day if selected date range is This Month or Previous Month.
 

`kpi_average_earing1`

The Merchant’s average earnings per transaction per hour for December 7th.
 

`kpi_average_earing2`

The Bank’s average earnings per transaction per month for November.
 

##### 3DS/non-3DS Ratio

Shows: The ratio of the number of 3DS/non-3DS sale, preauth, transfer transactions in approved, filtered and declined statuses to the total number of such transactions for the given date range.
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: The ratio of the number of 3DS/non-3DS sale, preauth, transfer transactions in approved, filtered and declined statuses to the total number of such transactions for the given date range per day starting from the month’s first date to the end date of the given date range.
 
Legend:
 

`colors1`

`3d_1`

The ratio of the number of transactions in different statuses for 3DS Gate for November.
 

`3d_2`

The ratio of the number of transactions in different statuses for non-3DS Gate for November.
 

`3d_3`

The ratio of the number of transactions in different statuses for November.
 

##### 3DS/non-3DS Ratio For Declined Transactions

Shows: The ratio of the number of 3DS transactions in declined status processed by the 3DS Gate, for Enrolled cards which have MPI status Y or A to the total number of transactions of the types sale, preauth or transfer for the given period
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: The ratio of the number of 3DS/non-3DS transactions in declined status per day for the given date range starting from the month’s first date to the end date of the given date range.
 
Legend:
 

`colors2`

`3d_approve_1`

The ratio of the number of transactions in declined status for 3DS Gate for November.
 

`3d_approve_2`

The ratio of the number of transactions in declined status for non-3DS Gate for November.
 

`3d_approve_3`

The ratio of the number of transactions in declined status for mixed traffic for November
 

##### 3DS/non-3DS Ratio For Approved Transactions

Shows: The ratio of the number of 3DS transactions in approved status processed by the 3DS Gate, for Enrolled cards which have MPI status Y or A to the total number of transactions of the types sale, preauth or transfer for the given period
 
Update frequency: virtually real-time (no more than 10 seconds delay)
 
Graph: The ratio of the number of 3DS/non-3DS transactions in approved status per day for the given date range starting from the month’s first date to the end date of the given date range.
 

`colors2`

`3d_decline_1`

The ratio of the number of transactions in approved status for 3DS Gate for November.
 

`3d_decline_2`

The ratio of the number of transactions in approved status for non-3DS Gate for November.
 

`3d_decline_3`

The ratio of the number of transactions in approved status for mixed traffic for November
 

> **Warning:** The MPI status and Enrollment status could be only determined if Payneteasy MPI plugin is being used or the Processor properly returns the data after 3DS verification.

### Black, White And Loyalty Lists

#### Overview

There are 3 types of access control lists, which work as filter checks in Payment Gateway. Lists are being checked while processing the transaction when the respective filter gets applied. BWL screen is designed to manage white, black and loyalty customer lists. This screen is located in Tools -> Black & White lists. It makes the process of putting the transactions’ attributes to respective lists faster and easier. It also has quick search which helps to find the exact transaction attribute added previously.
 

In order to select entries from list, specify manager and merchant/gate/processor for corresponding lists from dropdown menu.

 

It is possible to show any specific category from a certain list by clicking it in Category list to the right.

 

> **Note:** Lists are being checked while processing the transaction when the respective filter gets applied.

Processor lists will be available for choosing only after you set up gate with this processor in Project Strategy/Balancing Beta.
Gate lists will be available after setting up this gate in Project Strategy/Balancing Beta.

##### Black Lists

The first filter checking transaction attributes (email, IP, address, etc) is “Manager/Merchant black list”. It is possible to manage these attributes (excluding BIN) from the Order details screen. The attributes can have the following statuses:
 
 
> * attribute is in black list
> * attribute is not in black list
 
If any transaction attribute matches attribute in the lists and respective filter is enabled at the Project’s level, the transaction status is set to Filtered and the reason for filtering is saved in the transaction data (see [Error Codes in Transaction Filters](https://doc.payneteasy.com/integration/reference/transaction_filters.html.md) section in integration documentation).
 
For blacklisting IP addresses, it is important to note that most customers have dynamic IP which can be possessed by different customers of the same Internet provider. Mobile Internet users change IP address each time a session is created. It is also known that customers using traffic compression services (e.g. Opera Mobile) come via IP address of the proxy server provided by the service, most of which are located in Europe. According to statistics, if IP address is denied for more than 10 hours, the filtering will be in 80% cases false positive. This is why it is not recommended to filter transactions by IP without proper control. It is highly recommended prior to adding IP address into the black list to check with the Internet provider what maximal period of IP address denial can be applied. It is also important to check if the given IP address is in any third-party anti-spam systems.
 

##### White Lists

White list allows to skip additional filter checks for transactions with attributes in this list. The only attributes for whitelisting are: a card number and a customer DNA.
 
 

> **Note:** If the attribute is found in any white list the third-party fraud control systems’ checks are excluded either.

##### Loyalty Lists

Loyalty list is designed for merchants who work with the predefined set of customers. Database with customers can be managed on merchant side with PCI DSS certification, or on Payneteasy side. The system allows to manage the following several types of predefined clients lists such as names, emails, phones etc.
 
If any transaction attribute does not match attribute in the lists and respective filter is enabled at the Project’s level, the transaction status is set to Filtered and the reason for filtering is saved in the transaction data (see [Error Codes in Transaction Filters](https://doc.payneteasy.com/integration/reference/transaction_filters.html.md) section in integration documentation).
 
One-time box can be checked for automatic removal of customer from loyalty list after their first payment.
 

#### Adding New Elements To BWL

To add new elements, click on the ADD button. The type of the added criteria will be automatically identified. Ambiguous criteria type can be manually changed, as presented below. It is also possible to use `changebutton` button to switch between available options.

#### Importing Lists

In order to add many attributes to one of the lists at once, use IMPORT LIST feature.
 

For example, in order to add card number to list, the following order should be used for every line: (5555514066237247,12,2019) with ‘,’ delimiter between lines.
 
Some lists require a country code. See Alpha-2 Code in Reference section of Integration documentation: [country codes](https://doc.payneteasy.com/integration/reference/country_codes.html.md).
 
 

> **Note:** In case of disconnect or other technical problems during the process, contact technical support.

 
Imported files displayed in a separate table and sorted by ID in the “Last Imported from Files” section.
 

#### Exporting To File

In order to export your data into CSV file, use EXPORT LIST feature.
 

The data will be parsed according to set parameters.
 
Source card number and Destination card number export will be in 6+4 format. For complete data, please contact the support service.
 

#### Synchronizing Lists

##### Merchant

To synchronize two merchant lists, administrator can use SYNC feature. After synchronizing, lists from both merchants will filter transactions as if you joined your two lists.
 
 

> **Note:** Merchants do not have access to see entries from synchronized lists.

 

 

Synchronization can be cancelled by pressing the X button near the synced lists entry.

##### Gate

To synchronize two gate lists, administrator can use SYNC feature. After synchronizing, lists from both gates will filter transactions as if you joined your two lists.
 
 

> **Note:** Merchants do not have access to see entries from synchronized lists.

 

 

Synchronization can be cancelled by pressing the X button near the synced lists entry.

#### Available Lists For Every Role

#### Comments

When adding new records to the BWL lists, optionally, comments can be attached.
 
When adding records from order page, a comment will automatically be added with transaction id.
 
In order to display comment, point a cursor on «…» next to record in the list.
 

#### Order Details: Configuring BWL Lists

The attributes can also be added and removed from BWL on order details screen, as presented below:
 
 
- Select Merchant or Manager to switch between adding BWL list to Merchant or Manager.

 

 
- Press ADD TO LIST and select one of the shown lists:

- After selecting any list, select the criterion by which the card will be listed:

 
Blacklisted card will be shown in black colour:
 
 

 
Whitelisted card will be shown in green colour:
 
 

 
Card in loyalty list will be shown in Payneteasy colour:
 
 

 
- Several criteria can be chosen at the same time:

 

 
- Additional criteria can be added via section as shown below:

 

 
After adding criteria via section described above, parameters will have colours depending on the selected list:

### Endpoint Groups

Endpoint group is an entity that combines several Endpoints and Master Endpoints in different currencies. The Endpoint Group simplifies the integration of a Connecting Party business to Payneteasy Payment Gateway when working with various currencies. This screen allows to view configured Endpoint Groups.

 
Here is shown the structure and logic of Endpoint Group:
 
```plantuml
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 (Merchant)" #e1d5e7;line:black;line.dotted

"Connecting Party\n (Merchant)" -left-> "Endpoint\nGroup"
"Connecting Party\n (Merchant)" -down-> "layoutHelper3"
"Connecting Party\n (Merchant)" -down-> "Endpoint\n currency C"
"Connecting Party\n (Merchant)" -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 (Merchant)" -left[hidden]- "layoutHelper1"
"Connecting Party\n (Merchant)" -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
```

### Master Endpoints

#### Master Endpoint Overview

Master Endpoint is an entity which allows to set up Parallel form, also known as [Payment Cashier](https://doc.payneteasy.com/integration/api_use_cases/payment_cashier.html.md). Payment Cashier hosted on Payment Gateway side can display multiple payment methods for the Payer to choose from. Master Endpoint screen allows Merchants to configure such form and select which payment methods in which order will be available to each Payer according to Payer’s country.
 
Each specific payment method is configured on a separate Endpoint, and these specifically configured Endpoints are connected to Master Endpoint. Such Endpoints, connected to Master Endpoint, are called Auxiliary Endpoints. The Master Endpoint currency is inherited from the Project it’s linked to, but Auxiliary Endpoints don’t have to be in the same currency as Master Endpoint.
 

#### Master Endpoint Configuration

In order to create Master Endpoint, go to “Settings” -> “Configuration” -> “Master endpoints” and click the “+Master Endpoint” button.
 
 

 
After selecting Master Endpoint this screen will appear:
 
 

 
Click on the To details button to view Master Endpoint itself (filters, payment form, name and etc).
 
Click on the Edit button to configure:
 
• available payment methods and their order on the form (delete, move and etc.),
 
• initiated transaction type for each payment method (sale or preauth with capture),
 
• the list of countries for each payment method to be displayed.
 
To hide or show payment method use on/off button. Turning off payment method will turn it off only for current master endpoint.
 
For more information see [Payment Cashier Configuration](https://doc.payneteasy.com/manager/guides/payment_cashier_manager.html.md).
 

#### Payment Cashier Forms

It is possible to configure custom payment forms for Master Endpoint and each connected Auxiliary Endpoint. For configuration please see [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md) in integration documentation. Provide the customized forms to Payneteasy support manager for installation.

### Orders

#### Orders Search

The “Orders search” screen displays information on all transactions processed by Payneteasy. This screen is located in the “Orders” – “Orders search” section. Related transactions are grouped in Orders. Each Order has ID assigned by Payneteasy, ID assigned by Merchant or Connecting Party which represents Merchant and ID assigned by external processor (if transaction was processed in it). For example, sale transaction and subsequent refund on this sale transaction will have the same Order ID in Payment Gateway and will be searchable by both transaction types. Orders can also be accessed from Dashboard via Quick actions.

##### Find Orders

Basic search is performed by date and exact criteria:

 

Exact criteria can be used to assist in locating a specific transaction:

| `Main` | • merchant invoice id • order id in Payneteasy • processor order id • purpose • amount • session token |
|--------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `Customer` | • phone • email • IP address • IP address country • billing country |
| `Source Card` | • bank name • country • card from order id • BIN • BIN range from order • last 4 • 6+4 • approval code • ARN • RRN • card holder • card ref id |
| `Destination Card` | • bank name • country • card from order id • BIN • BIN range from order • last 4 • 6+4 • approval code • ARN • RRN • card ref id |
| `Wire` | • account number • routing number. |
| `Card Present API` | • reader ID • reader key serial number • reader device serial number |
| `Mobile API` | • device serial number • phone serial number • phone IMEI |

The most convenient criteria to find an exact transaction are:

* 6+4 digits, which allows to most accurately search for a specific card;
* approval code and RRN (can be obtained from a bank statement or from a transfer receipt);
* transaction ID.

Additional search criteria are used to help with the selection of relevant orders list.
 
The following criteria are available:
 

| `Card types` | allows to view transactions with a specific type of cards and payment methods; |
|------------------------|----------------------------------------------------------------------------------------------------------------|
| `Currency` | allows to select one or more currencies; |
| `Transaction types` | allows to view only the specified transaction types; |
| `Transaction statuses` | allows to view transactions with the specified status; |
| `Order status` | when the transaction can’t be found, this criterion allows to track the order on all stages of its processing; |
| `Endpoint` | allows to view all transactions on selected endpoints; |
| `Project` | allows to view all transactions for a specific project or several projects; |
| `Gate` | allows you to display all transactions on selected payment gateways |
| `Processor` | allows you to display all transactions for a specific processor or multiple processors |
| `Company` | allows you to display all transactions for selected companies |
| `Merchant` | allows you to display all transactions for a specific Merchant or multiple Merchants |
| `Reseller` | allows you to display all transactions for a specific reseller or multiple resellers |
| `Error code` | allows to view all transactions with a specific error. |
After selecting one or more search criteria, click Search.
 

##### Orders View

By default, orders in Payment Gateway are displayed as follows:
 
 

 
Orders can be presented in a Brief or Detailed view. This can be switched with the following button:
 
 

 
In detailed form, the orders will be displayed as follows:
 
 

 
The number of orders displayed on one page can be changed with the buttons in the “Rows” column:
 
 

 
The Date button performs sorting by date. By default the latest transactions will be displayed on top.
 

##### Download Of Selected Transactions Report

To download the sorted transactions, click one of the following buttons:
 
- download to Excel format
 
- download to CSV format.
 
An additional menu can be used to manage export fields:
 
 

 
In the pop-up window, select necessary data and save the list:
 
 

##### Order Details Screen

Order details screen is opened by сlicking on the order ID from the search screen.
 
Order details, such as IDs and order creation time, are displayed on the left side of this screen:
 
 

 
First six and the last four digits of the card number, card expiration date and cardholder name are displayed on the card. There is also information about country, bank, card type and the payment system of the card.
 
 

 
Next to the sender and receiver cards are buttons to add card details to Black, white and loyalty lists.
 
 

 
Additional customer data sent by the Merchant or submitted by customer on the form is displayed under the card or other payment method indicator. Clicking on cardholder or customer data parameter (for example, e-mail address) initiates a search for all transactions with a selected parameter.
 

Click on one of the plus signs near the customer data parameter (highlighted in red on the picture) adds this parameter to black, white or loyalty list. Additional click on this sign removes the parameter from respective list:
 
 

If Merchant is added to Customer Management module - new CMS customer can be created manually:
 
 

 
After pressing Create CMS customer - fill in needed fields, assign new “Merchant customer ID” and press Create button. New customer will not be created if “Merchant customer ID” is not unique.
 
 

 
If the client already has a CMS level, it will be indicated in the transaction details and client details
 
 

 

 
All transactions within the order are grouped and the commission for each operation is calculated.
 
This screen has the functionality to leave notes. For example, notes for transaction documents, customer contacts, or any other information related to this order.
 
 

 
Current transaction status can be seen in the upper right part of order screen:
 
 

 
General information on all transactions associated with provided customer data is displayed in the top panel.
 
The total amount of all transactions made by the specified cardholder and the number of approved/declined/filtered/etc transactions:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified E-mail:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified IP address:
 
 

 
The total amount of transactions and the number of approved/declined/filtered/etc transactions with the specified card number (PAN):
 
 

##### Captures And Cancels From Back Office

If Preauth has final successful status, the Merchant can initiate cancel which cancels the deduction and returns locked amount back to customer’s card or the Merchant can initiate capture which deducts the locked amount from customer’s card.
To start a cancellation or capturing (deduction) of the transaction, go to the details of the relevant order.
On the order details page, click the Cancel order button for cancellation of deducting and Capture order for deducting the locked amount.

##### Refunds From Back Office

If the order has final successful status, the Manager can return the money to the customer, on their request, for instance.
To start a refund (reversal) transaction to the customer card, go to the details of the relevant order.
On the order details page, click the Reverse order button.

 

The dialog box will open like presented below:

 

In this dialog box specify the amount of reversal. It can be the entire amount of the order, or only a part of it for cases where the Merchant refunds payment for certain goods that are part of one order.
In the Comment field a description of this refund can be added.

> **Warning:** Merchants must be extremely careful when making a refund on the order! Refund requests are immediately sent to the bank and it will not be possible to cancel this transaction from the Payneteasy system afterwards.

##### Callbacks From Back Office

If the order has final status and had server_callback_url in the initial request, the Merchant can re-send the final callback.
To send a callback to the Connecting Party, go to the details of the relevant order.
On the order details page, click the Callbacks button.

The dialog box will open like presented below:

 

In this dialog box click Send Again to resend the callback to the Connecting Party. If the
callback is not sent successfully, click Send Again to retry, or click Cancel to cancel the callback.

 

| Callback Fields | Description |
|---------------------|------------------------------------|
| Event ID | Callback event identifier |
| Callback URL | Callback receiver URL |
| Transaction type | Type of the transaction |
| Transaction status | Transaction status |
| Last fire date | Time of the last callback attempt |
| Next fire date | Time of the next callback attempt |
| Retry count current | Remaining automatic retry attempts |
| Job processed | Callback job processing status |
 

Callback Sending Logic

| `Job processed = N` | • callback sending is active • automatic retries will occur • Cancel button is available |
|-----------------------|-----------------------------------------------------------------------------------------------------------------------------------------|
| `Job processed = Y` | • callback sending is stopped • automatic retries will not occur • Cancel button is not available |

When the Send button is pressed, a single manual callback is sent and the `Retry count current` will decrease by 1.
The status will change from: Y → N if the callback attempt fails.

You can stop callbacks by pressing Cancel.

When the Cancel is pressed:
The status will change from: N → Y, callback will stop and no further automatic attempts will occur.

> **Note:** Cancelling a callback prevents any further automatic retry attempts until the callback is manually triggered again.

##### Change Status From Back Office

If the order has final status, the Manager can change the status from declined to approved (and the other way around).
To change the order’s status manually, without requesting a status from provider, go to the details of the relevant order.
On the order details page, click the Change Transaction Status button.

 

The dialog box will open like presented below:

 

| `Transaction Date and Time` | Allows to change date and time of transaction. Leave it blank to keep existing date and time without change. |
|-------------------------------|--------------------------------------------------------------------------------------------------------------------------|
| `Amount` | Allows to change the order’s amount. |
| `Result Status` | An order’s status (DECLINED/APPROVED) should be chosen. |
| `External ID` | Allows to change External Order ID. |
| `RRN` | Allows to add a retrieval reference number of the transaction. |

If there is more than one completed transaction (Gate) in the session, the user will be presented with a list of
transactions and can select which one to update.

 

Only transactions with a final status will appear in this selection list.
Transactions with a non-final status will not be included.
If there is only one transaction with a final status in the session, the transaction selection list will not be displayed in the context window.

> **Warning:** Please note that once the needed gate is chosen, all the subsequent gates after this gate will be deleted from the transaction.

If the order has a final declined status and there is more than one gate in the chain, the Manager can use the
Rollback transaction & query status button to request the latest transaction status from the provider.

 

By pressing this button, a status request will be sent to the provider, and the transaction will be updated with the provider’s latest status.

#### Recurring Payments

The screen is located in the “Orders” section.
 
This screen displays recurring payments (for example, subscriptions).
 
Basic search is performed by date and exact criteria:
 
 

 
The Criteria button contains additional search parameters:
 
 

| `Recurrence status` | Allows to select the specified repetition status of the recurring transaction: Failed – unsuccessful attempt; Scheduled – planned attempt; Stopped – currently paused or finished attempt. |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `Recurrence type` | Allows to select the specified repetition type of the recurring transaction: Manual – recurring payments are initiated manually; Auto – recurring payments are initiated automatically in accordance with the set schedule; Native- recurring payments use special integration with the acquiring bank. |
| `Endpoint` | Allows to select the specific endpoint if there are several endpoints available. |
| `Project` | Allows to select the specified project if there are several projects available. Select one or more search criteria and click Search to find the needed transactions. |

#### Ethoca Alerts

This section allows to see alerts from Ethoca which helps in preventing chargebacks:

#### Chargeback Help

This section allows to see alerts from Verifi which helps in preventing chargebacks:

### Transaction Statuses And Types

#### Transaction Types

Payneteasy processing platform divides all transactions into several types, depending on the purpose of each transaction. Each transaction has a specific status.

| `sale` | Acceptance of payment for provided goods or services in a single operation; |
|------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `preauth` | Blocking of a fixed amount of money on the card for the subsequent withdrawal (financial pledge). The cardholder will not be able to use the held funds, however, this money will not be withdrawn from the bank account until a subsequent request (capture) is received from the merchant. After a certain period of time, if a follow-up request is not received from the merchant, the holding of this funds amount is cancelled and it will become available for use again. |
| `capture` | Withdrawal of the previously held by “preauth” transaction funds from the cardholder bank account. |
| `cancel` | Cancellation of fund holding by “preauth” transaction. |
| `reversal` | a refund operation for previously approved transaction (“sale” or “preauth” followed by “capture”). For example, a cancellation of an order by the customer, or a partial return of goods to the store. |
| `transfer` | Peer-to-peer (p2p) transfer transaction between 2 cards. This transaction can be split into 2 steps in some cases - card2account and deposit2card. |
| `chargeback` | Forced refund operation initiated by the cardholder, or the issuing bank, in case of fraud. |
| `fraud` | Special marker for fraudulent transactions. |
| `retrieval` | Request of additional documents for disputed or suspicious payment. Documents can be requested from the merchant or from their agent (service provider). |
| `account verification` | Validation of Payer’s card account information. |
| `payout` | Transfer of funds from Connecting Party banking account to customer (receiver) banking account or digital wallet. |

#### Transaction Statuses

All transactions are marked according to their statuses:

| | `Approved transaction` | The transaction was processed by the acquirer successfully (payment was made as part of the transaction), final status. |
|----------------------------------------------|--------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| | `Declined transaction` | For any technical reason the acquirer cannot process the transaction. For example, this may be caused by insufficient funds on the customer card or account, final status. |
| | `Filtered transaction` | The transaction was filtered by Payneteasy Payment Gateway and was not processed, final status. |
| | `Error` | Processing of transaction failed. A second attempt can be made to process the transaction. If the error occurs again, contact the Payneteasy support service, final status. |
| | `Unknown` | Payment Gateway failed to get final transaction status. Contact the Payneteasy support service to clarify the transaction status, non final status |
| | `Failed` | System’s internal status. It means there are no available settings to route transaction in the system due to filter restrictions, final status. |
| | `Processing` | Transaction is being processed, should continue polling. If transaction status haven’t been changed for one hour something went wrong, please stop polling and inform your payment gateway manager, non final status. |

> **Note:** after reconciliation transaction status could be changed even if transaction is in final status

### Payneteasy MCP Server

#### Introduction

A step-by-step guide to connecting the Payneteasy stateless Streamable HTTP MCP server to Claude Desktop, Claude Code and other AI agents, authenticated with a restricted access token.

| Key Concepts | |
|---------------------|-------------------------------------|
| Production endpoint | `https://gate.payneteasy.eu/mcp-ui` |
| Authorization | `Authorization: Bearer <token ` |
| Transport | `Streamable HTTP (stateless)` |
| Token rights | `MCP Read Only` |

> **Note:** The server is **read-only**. A `MCP Read Only` token cannot mutate platform state — every exposed tool is annotated `read Only Hint: true`.

#### MCP server URLs

Pick the endpoint that matches your environment. The configuration examples throughout this guide use the **production** URL — replace it with the sandbox URL when needed.

| Environment | MCP endpoint | Purpose |
|----------------|----------------------------------------|------------------------------|
| **Production** | `https://gate.payneteasy.eu/mcp-ui` | Live payment traffic |
| **Sandbox** | `https://sandbox.payneteasy.eu/mcp-ui` | Safe testing and integration |

> **Warning:** The restricted access token is issued **per environment**. Create the token in the profile of the same environment you intend to connect to. A token from one environment will not work on another.

#### Get a restricted access token

Access to the MCP server uses a Bearer token. Payneteasy uses a **restricted access token** — it grants rights only to a selected set of operations. The `MCP Read Only` profile is enough to connect MCP.

##### Step 1 — Open user profile

Go to the *Restricted tokens* section: Profile → Restricted tokens.

`User profile with the Restricted tokens section`

##### Step 2 — Click “Create token”

To create token, press the Create token button in the top-right corner of the Restricted tokens page.

`Restricted tokens page with the Create token button`

##### Step 3 — Fill in the token parameters

| Field | Value |
|------------------|---------------------------------------|
| Name | any token name, e.g. `mcp-1` (1) |
| Lifetime in days | up to `180` |
| Access rights | tick the `MCP Read Only` checkbox (2) |
`Create token form with name, lifetime and MCP Read Only checkbox`

##### Step 4 — Create and copy the token

Click Create token (top-right of the form), then copy the token value and save it.

`Window with the created token and the Copy to clipboard button`

> **Warning:** The token is shown **only once**. Click Copy to clipboard and store it safely. The value cannot be viewed again. It is a long JWT string of the form `eyJ…`.

#### Claude Desktop

To connect to MCP successfully, install **Node.js** first.

##### Installing Node.js

1. Download the LTS installer for your OS from [nodejs.org](https://nodejs.org).
2. Run the installer, keeping the default options.
3. Restart the terminal (and Claude Desktop) so it picks up the new PATH.
4. Check the install:
   ```bash
   node -v
   npx -v
   ```

 Both commands should print a version number, e.g. `v20.11.0`. If `npx` is not found, reopen the terminal or restart the computer.

##### Configuration: via mcp-remote

**File Location**

Claude Desktop connects to remote MCP servers through a configuration file. Since Payneteasy server uses an HTTP transport, it is added to the `mcp Servers` section.

| OS | Path |
|---------|-------------------------------------------------------------------|
| macOS | `~/Library/Application Support/Claude/claude_desktop_config.json` |
| Windows | `%APPDATA%\Claude\claude_desktop_config.json` |
It can also be opened from the app: Settings → Developer → Edit Config.
 
Next **close the Claude application**.
 

> **Note:** In every configuration below, replace `<ACCESS_TOKEN>` with the value you copied. The token is sent to the server in the `Authorization: Bearer <ACCESS_TOKEN>` header.

##### claude_desktop_config.json — mcp-remote

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "npx",
      "args": [
        "-y",
        "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

##### Windows: fixing the startup issue

On Windows, launching `npx` by an absolute path often breaks because of the space in `C:\Program Files\nodejs`. The fix is to run it through `cmd /c npx` with a bare `npx` — it is picked up from `PATH`, so the space no longer breaks argument parsing:

##### claude_desktop_config.json — Windows

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "cmd",
      "args": [
        "/c",
        "npx",
        "-y",
        "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

That is, `command` = `cmd`, and `npx` becomes the first argument after `/c`. The resulting command line is `cmd /c npx -y mcp-remote …`, and the space in “Program Files” no longer matters.

> **Note:** If it still misbehaves, as a fallback specify the 8.3 short path: `"command": "C:\PROGRA~1\nodejs\npx.cmd"`. But the `cmd /c npx` variant is usually enough.

##### Configuration: via HTTP

If version of Claude Desktop does not support a direct HTTP transport, use the `mcp-remote` bridge:

##### claude_desktop_config.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

> **Note:** After saving the file, **fully restart Claude Desktop**. The connected server appears in the tools menu (the “🔌 / Search and tools” icon).

#### Claude Code

In Claude Code, MCP servers are added with a single `claude mcp add` command or via a `.mcp.json` file in the project root.

##### Via the CLI

The fastest way is to add an HTTP server with an authorization header:

##### Terminal

```bash
# transport http, server name Payneteasy
claude mcp add --transport http Payneteasy \
  https://gate.payneteasy.eu/mcp-ui \
  --header "Authorization: Bearer <ACCESS_TOKEN>"
```

Visibility is set with the `--scope` flag:

| Scope | Description |
|-----------|-----------------------------------------------|
| `local` | only for you in the current project (default) |
| `project` | in `.mcp.json`, shared with the team via git |
| `user` | available across all projects |

##### Checking the connection

##### Terminal

```bash
claude mcp list           # list servers and their status
claude mcp get Payneteasy # server details
```

Inside a Claude Code session, the status is checked with the `/mcp` command.

##### Via the project file

To make the server available to the whole team, add a `.mcp.json` to the repository root. It’s best not to commit the token — move it to an environment variable:

##### .mcp.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer ${PAYNET_MCP_TOKEN}"
      }
    }
  }
}
```

##### Terminal

```bash
export PAYNET_MCP_TOKEN="<ACCESS_TOKEN>"
```

> **Note:** Claude Code expands `${VAR}` from the environment at startup. Commit `.mcp.json` to the repository, and keep the token itself in a local `.env` / secret manager.

#### Other AI agents

The principle is the same for every client: point to the endpoint `https://gate.payneteasy.eu/mcp-ui`, use the **Streamable HTTP** transport, and the `Authorization: Bearer <ACCESS_TOKEN>` header. Below are concrete configurations for popular agents.

##### Cursor

File: `~/.cursor/mcp.json` or `.cursor/mcp.json` in the project.

##### .cursor/mcp.json

```json
{
  "mcpServers": {
    "Payneteasy": {
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

Then: **Settings → MCP → Enable** for the `Payneteasy` server.

##### VS Code (Git Hub Copilot / Agent Mode)

File: `.vscode/mcp.json`.

##### .vscode/mcp.json

```json
{
  "servers": {
    "Payneteasy": {
      "type": "http",
      "url": "https://gate.payneteasy.eu/mcp-ui",
      "headers": {
        "Authorization": "Bearer <ACCESS_TOKEN>"
      }
    }
  }
}
```

Start the server via the *Start* button above the block in `mcp.json` or with the `MCP: List Servers` command.

##### Cline · Windsurf · other MCP clients

Most clients use a single format. If a client only supports stdio, wrap the HTTP server with `mcp-remote`:

##### mcp settings (generic)

```json
{
  "mcpServers": {
    "Payneteasy": {
      "command": "npx",
      "args": [
        "-y", "mcp-remote",
        "https://gate.payneteasy.eu/mcp-ui",
        "--header",
        "Authorization: Bearer <ACCESS_TOKEN>"
      ]
    }
  }
}
```

##### Manual check (curl)

Before configuring an agent, you can verify that the token works:

##### Terminal

```bash
curl https://gate.payneteasy.eu/mcp-ui \
  -H "Authorization: Bearer <ACCESS_TOKEN>" \
  -H "Content-Type: application/json" \
  -H "Accept: application/json, text/event-stream" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/list"}'
```

The response should contain the list of available tools — that means the server and token are configured correctly.

#### Domain model

The server ships a domain model in its `instructions` field so an agent knows how the entities relate before it calls any tool. The model is reproduced here.

##### Orders and transactions

* An **order** is a customer purchase attempt. It contains one or more **transactions**: pre-authorization, capture, refund, chargeback.
* Transaction statuses are **approved**, **declined** and **filtered** (*filtered* = blocked by fraud-prevention rules before processing).

##### Statistics tools

The `stats_*` tools return **aggregates** (counts and amounts) — never individual orders. Use `orders_search` to find specific orders.

| Scope | Description |
|----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| stats_get_transaction_timeseries | Returns count + amount per time bucket (day / week / month), split by transaction status. |
| stats_get_transaction_summary | Returns sales / reversals / chargebacks / frauds / disputes (counts + amounts + ratios) for a date range, broken down by card type, with a grand total. |
| stats_list_top_entities | Ranks merchants / companies / processors by a metric over a date range (highest first); reuse the returned ids in the `*_get_details` tools or as stats filters. |
| stats_get_breakdown | Splits a metric over a date range (bar chart) by transaction status, card-issuer / IP country, or decline / chargeback / fraud reason. Same filters as the timeseries tool. |

##### Order tools

| Scope | Description |
|--------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| orders_get_details | Returns one order by id: the order/transaction summary, the customer’s card metadata + masked contact, and the merchant routing. Sections appear only for the order APIs the token may call. |
| orders_search | Finds orders by a change-date window with optional status / entity filters and paging; returns safe order summaries. Use `orders_get_details` for one order’s full detail. |
| orders_get_logs | Returns an order’s processing session stages (the log trail), each stage with its message; `mode=UNLIMITED` for the full set. |

##### Resolving ids

Resolve currency / card-type ids via `refs_list_*`, and merchant / processor / manager / etc. ids via the `*_search` tools, before using them as stats filters.

### Merchants

#### Creating Merchant

To see and search all Merchants, go to Settings -> Users -> Merchants, then in order to create new Merchant press to + New Merchant button:

Below are all the fields available for filling in:

| Field name | Description | Necessity |
|-------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------|
| Login | Login which is required while logging in the system. **Cannot be changed after creation**. | Required |
| Password | Password for login. In order to change it, contact support. | Required |
| Display Name | Merchant name which will be displayed. | Required |
| E-mail | Contact E-mail which will be added to this Merchant account. | Required |
| Control Key | Secret key which will be used for signing requests. | Required |
| Payment group | Currently not in use. “Common” is a default value. **Cannot be changed after creation**. | Required |
| Name | Shows Merchant’s contact person name. This name will be displayed only in merchant details. | Required |
| Surname | Shows Merchant’s contact person surname. This name will be displayed only in merchant details. | Required |
| Business type | Will show which business type Merchant has. | Optional |
| Returning customer approve sessions count | Shows after how many approved transactions, Payer will be considered as Returning for Merchant. | Optional |
| Registration country | Shows Merchant country. | Optional |
| Merchant site URL | Merchant site URL can now be set on Merchant details screen and included in E-mail notifications (MERCHANT_SITE_URL macro). | Optional |
| Organization | Shows Merchant’s organization name. | Optional |
| Tags | Shows tags by which Merchant can be found later in system. | Optional |
| API descriptor | Manager can set API descriptor parameter in the Merchant profile. This value will be returned instead of gate values specified in [Gate Details](https://doc.payneteasy.com/manager/configuration/gate/gatedetails.html.md). | Optional |
| Email for Notifications | Merchant email addresses for automated notifications regarding transaction status changes to Fraud or Chargeback. Supports multiple recipients. | Optional |

#### Merchant details

The screen allows to view all details of created merchant, change settings, configure merchant balance and view linked endpoints.
 

##### Linked Endpoints

This section by default display enabled linked endpoints to merchant. By selecting Show disabled endpoints the sheet will be replaced and will display disabled linked endpoints.
 
 
`linked endpoints`

#### Account balance

##### Introduction

Manager can configure and view multiple balances for each Merchant account and [request balances by API with manager access](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_manager.html.md). These balances calculate the total accumulated funds from transactions associated with Merchant. Balances calculation supports configured rate plans, including STH - Short-Term Hold and RR - Rolling Reserve.
 
Manager can add adjustments to Merchant balances on UI or with [adjustment API](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_merchant.html.md) to reflect non-transactional changes in Merchant balance. See [Get Balance Adjustments](https://doc.payneteasy.com/integration/API_commands/accounts_adjustments.html.md).
 
By default Merchants can’t see their balances on UI or [request balances by API with merchant access](https://doc.payneteasy.com/integration/API_commands/api_v2_get_balance_merchant.html.md) , but this functionality can be granted to each Merchant individually.
 
 
Merchant balances can be configured via Accounts tab on Merchant details screen.
 
To set up calculation of balances, follow these steps:
 
1. Set [Account configuration](#account-configuration) to define how and which transactions and rates should affect [balances](#account-configuration).
 
2. Set [Balances](#balances) for required [currencies](#currencies-balances) and [endpoints](#endpoint-setting).
 
3. Set [Account configuration override](#account-configuration-override) for specific [Balances](#balances) (if needed).
 

First balance is funded by sale transactions and defunded by payout transactions and is set up for USD currency, also Merchant rates applied for sale transactions.
Second balance has override for sale transactions which will deduct balance with amount calculated from manager rate plan.

Below is the example of fully configured balance with highlighted steps.

`configured balance`

##### Account configuration

Merchant’s accounts can be configured via Accounts tab. See example of accounts window below:

`accounts tab`

###### Application Rate Direction

Transactions with rate only can select both ADD and DEDUCT. For each transactions apply rate can be specified differently. For example, if it is needed to deduct a commission for a Payout transaction in addition to deducting the amount of the Payout itself then need to choose DEDUCT in the Apply direction configuration.

###### Application Impact on Balance

Different types of transactions count differently when calculating balances. List of application impact on balance is shown in the table below:

| Transaction type | Impact on balance |
|-------------------------|---------------------|
| sale | Add |
| capture | Add |
| dispute | Add |
| chargeback_reversal | Add |
| arbitration | Add |
| payout_cancel | Add |
| chargeback | Deduct |
| prearbitration | Deduct |
| reversal | Deduct |
| payout | Deduct |
| transfer (deposit2card) | Deduct |
| preauth | Rate only |
| cancel | Rate only |
| fraud | Rate only |
| retrieval | Rate only |
| pan_eligibility | Rate only |
| create_card_mapping | Rate only |
| update_card_mapping | Rate only |
| inquire_card_mapping | Rate only |
| delete_card_mapping | Rate only |
| mfo_scoring | Rate only |
| account_verification | Rate only |
| void | Rate only |

###### Rate Types

For each type of transaction, Manager can separately apply the rate (commission). Possible rate types are:

* Nothing
* Merchant
* Reseller
* Manager
* Dealer
* Acquirer

###### Date Bumping Functions

Date bumping functions allows to choose when the funds will be credited to the account. Possible values are:
 
> * ASAP - crediting funds without delay. Doesn’t include STH and Rolling Reserve.
> * ASAP_plus_RR - crediting funds ASAP and counts Rolling reserve. Doesn’t include STH.
> * DAY + n - crediting funds from STH after the specified number of days + Rolling Reserve.
> * BDAY + n - crediting funds from STH after the specified number of business days + Rolling Reserve.
 
`date bump`

###### Add account configuration

To create new account balance, add account configuration and balance:

1. To add new account configuration press +Add button in configuration field and set up the transaction type and rates, which will add or deduct funds from balance by settings described in [Accounts Configuration](#account-configuration). Optionally, gate and endpoint can be selected - if they are left empty, balance configuration will work for all gates and endpoints of selected Merchant.

 
`add conf`

##### Balances

###### Add balance

1. To add new account balance press +Add button in account balances field and set up balance and manager name and currency. Detailed setting of account balance is described below in this section.

 
`adding account balance`

###### Types

There are four types of funds for each balance:

###### Balance Total

Balance Total - amount of funds calculated based on configuration, including STH and RR.

 
`balance total`

###### Balance Live

Balance Live - amount of funds calculated based on configuration, excluding STH and RR.

 
`live balance`
 

###### Short-Term Holds

Short-Term Holds - amount of funds calculated based on the Date bumping function.

 
`sth`
 

###### Rolling Reserve

Rolling Reserve (Long-Term Holds or Holds from Rate Plan) - amount of funds calculated based on the rate plan hold.
Max Rolling Reserve - a limit on the amount of Rolling Reserve.

 
`Max Rolling Reserve`
 

Max Rolling Reserve can be changed in the Change Max Rolling Reserve window that appears. To set or edit the Max Rolling Reserve, click on the value -.

 
`Change Max Rolling Reserve`

> **Warning:** Rolling reserve will be credited to balance on Transaction Date + Period from Rate Plan + 1 day. When the Max Rolling Reserve limit is reached, the total amount of hold funds will not increase and the Rolling Reserve calculated from next transactions will be added to balance live instead. Also, If the Max Rolling Reserve is set later and is less than the current accumulated Rolling Reserve, then the Rolling Reserve calculated from next transactions will be added to the balance live.

###### Endpoint Setting

There is possibility to selecting one or more endpoints for each balance, according to which balance will be calculated.

Endpoint can be added when creating a balance:

 
`add acc balance`
 

Or it can be specified for an existing balance by clicking on one of the area highlighted in the picture:

 
`acc debit`
 

This picture also displays the difference between the balances configured with and without the specified Endpoint.

###### Multiple Balances In One Currency

There can be several balances configured for the same currency.

In this case, only one of the balances can be without the specified Endpoints.
When creating all subsequent balances, it is mandatory to specify the Endpoint.
The calculation is made for each balance separately: the balance without the specified Endpoints is counted only for those Endpoints for which a separate balance has not been created.

 
`edit balance`

##### Account configuration override

There is possibility to change configuration for every balance (not for all Merchant’s balances).

For this case need to press Configuration button as in the picture below:

 
`conf over ride`
 

And after this press the Add button:

`over ride add`
 

In this window can be changed the balance settings as well as in the Configuration

> **Warning:** If at least one operation type is overrode, balance will count by overrode configuration and only for overrode operations. If there is no override for operation types, than balance will counts by main configuration.

Example: For balance 191 Sale and Payout operations are overrode, that means for this balance main configuration doesn’t affect.

`conf over ride done`

To remove configuration override press Remove all button and confirm the deletion.

###### Creation Date Changing

To change balance created date press Change created date button:

`change date account balance`

Select date of creation and press Update button:

 
`change date confirm account balance`
 

After changing the creation date, use [reconciliation](#accounts-reconciliation) to recalculate the balance.

###### Export Balance Transactions

To use Balance reconciliation press on Reconciliation balance button:

`rece xbut`
 
To export balance transactions press on Export Transactions button and select transactions’ period:
 
 
`rece xbut`
 
`period field`
 

> **Note:** The maximum period is 31 days.

> **Note:** The date is counted as [day_From, day_To), so the last day will not be included in the interval.

CSV file contains the following fields:

 
`balance exp`
 

> **Warning:** “Reserve date” and “STH date” fields are the date and time when amount will affect the balance. The STH date in report doesn’t count hourly period described in balance types.

###### Balance Reconciliation

Reconciliation allows to recalculate balance after changes.

To reconcile balance press 3 dots near balance then Reconciliation Balance button and after Reconcile button:

 
`rece xbut`
 

> **Note:** Only Total and Live balances are reconciled. RR and STH can not be reconciled; their amount will be credited to live balance according to the configuration at the time the transaction was created.

Move Rolling Reserve allows to manually transfer the Rolling Reserve to the active balance, before the release date of the holding. To move Rolling Reserve press 3 dots near balance then Move Rolling Reserve button:

 
`rece xbut`
 

##### Adjustments

Adjustments allows to change balances amount without making any transactions.

List of adjustments and full adjustment amount can be viewed by clicking on Adjustments button:

 
`adj`
 

For the convenience of users, adjustments can be sorted by ID using the button below:

 
`adj ID filter`

###### Manual Adjustment

Adjustment amount and external source of the adjustment are mandatory. Adjustments for balance can be made via Add+ button:

 
`adj click`
 

When adding adjustment, next fields can be specified:

* Adjustment amount
* External ID
* External source
* External info

> **Note:** Adjustment amount and External source are mandatory fields:

 
`add adj`

###### Adjustment API

In addition to manual adjustments, it is possible to make adjustments via API.

To do this, a tsv has to be created, zipped and sent via the API. API command with examples is specified in the [integration documentation](https://doc.payneteasy.com/integration/API_commands/accounts_adjustments.html.md).

###### Export Adjustments

To export all adjustments for specific balance press the Export button, specify period of time and after that press Export button. The csv file of adjustments will download automatically.

> **Note:** The maximum period is 31 days

Downloaded file contains next fields:

* Create Date
* Adjustment Amount
* Adjustment Application Date
* External Adjustment Unique Id
* External Source Name
* External Adjustment Info

The first line of the file contains the period and the sum of all adjustments.

`adj ex`

###### Scheduled Adjustment

This functionality helps to configure a monthly/weekly fee, which can be set up on the appointed dates every month/week. Scheduled for balance adjustments can be made via Add+ button :

 
`scheduled add`
 

When adding adjustment, next fields can be specified:

* Date of first adjustment
* Date of last adjustment
* Amount
* Currency
* Automatically stop creating adjustments when a merchant is disabled
* Automatically stop making adjustments when balance goes negative or zero
* I am aware that the creation of such an adjustment can significantly affect the balance of the merchant, and lead to its uncontrolled change in the long term, which can cause financial losses due to the possibility of unlimited withdrawal of funds due to an uncontrolled increase of the merchant balance. **This checkbox is mandatory**

 
`scheduled add1`

Status indicates whether the adjustment is active or not. It can also be turned on or off by clicking on it:

 
`scheduled status`
 

ID is unique identifier of the scheduled adjustment:

 
`scheduled id`
 

Period shows which schedule is selected for the following adjustment:

 
`scheduled period`
 

Date shows time interval from first adjustment to the last adjustment:

 
`scheduled date`
 

Next schedule date shows when is the next scheduled adjustment:

 
`scheduled next date`
 

Last run date shows when was the last scheduled adjustment:

 
`scheduled lastate`
 

Amount shows the adjustment amount:

 
`scheduled amount`
 

Automatic shows in which conditions scheduled adjustment will be stopped:

 
`scheduleda utomatic`
 

Edit can be used to edit scheduled adjustment:

 
`scheduled edit`
 

Delete can be used to delete scheduled adjustment:

 
`scheduled delete`

### Merchant Cashflow Report

This report calculates transaction turnovers: sale, chargeback, and reversed funds. It shows the distribution of turnover with commissions and the approximate profit for the selected period, as well as day-by-day earnings.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Merchant Daily Performance Report

This report displays the day-by-day financial flow for a given period.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
The report can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Merchant Online Balance Reconciliation

This section displays information about all Merchants reconciliations. In order to turn off all reconciliation notifications press `unmute` button.

 

> **Note:** Alert will come only if “DIFF” parameter will be more than 1000$ (equivalent for other currencies)

### Monitoring

### Payment Cashier Configuration

#### Introduction

Payment Cashier integration requires a configured Master Endpoint to display Cashier Form (also called Parallel Form) and configured Auxiliary Endpoints for each payment method to be displayed on the Parallel Form. The Manager can configure on Master Endpoint which transaction type (sale, preauth) will be initiated for each payment method and for which list of countries this payment method will be displayed. There can be several payment methods, such as Credit Card, Bank Transfer, etc. on the same Parallel Form available for the Payer to choose from.

#### Parallel Form Master Endpoint Settings

There is an instruction for Project configuration to use Parallel Form:

1. To configure Parallel Form that includes payment methods in different currencies, at least one Project for each currency should be created. For example, if payments in USD, EUR and JPY are to be processed, 3 different Projects must be created accordingly.
 
 
2. After Projects were created, all required Endpoints for provided payment methods have to be created and connected to appropriate Projects. All these Endpoints will be auxiliary to Master Endpoint and called Auxiliary Endpoints.
 
 
3. To create Master Endpoint, go to (Settings -> Configuration -> Master Endpoints -> + Master Endpoint).
 
 
4. Auxiliary Endpoints, which represent payment methods, must be connected to the Master Endpoint to be displayed on the Parallel Form. This can be done in Master Endpoint settings. To add new Auxiliary Endpoint, press the Add button. The form with three following fields should be filled: “Endpoint”, “Payment method” and “Payment method reference name”. In the “Endpoint” field one of the available Endpoints should be chosen. The “Payment method” field defines the name of the payment method shown on the relevant Parallel Form tab. “Payment method reference name” field defines the internal reference name of this payment method, which can be used for customization of this payment method display style in Parallel Form template.
 
 
5. After the Auxiliary Endpoint is added, the Manager may also select which transaction type will be initiated (sale, preauth) and set the list of countries where this payment method will be available. To select the list of countries, press the three-points button that stays opposite of the Auxiliary Endpoint field.
 
 
6. To change the default Parallel Form template, go to the Master Endpoint (Master endpoint details screen -> Common -> Edit -> Payment form template). To change the default payment form template for particular payment method, go to the respective Auxiliary Endpoint details screen and set the corresponding Payment form template. Such form template returning algorithm is used for all kinds of form templates: payment, waiting and finish templates. See Payment Page Display Logic in the next section for details.
 

> **Note:** It is also possible to set the payment form template in the Project settings (Project details screen -> Common -> Edit -> Payment form template). When the request is sent to Master Endpoint without a specified Parallel Form template, Master Endpoint inherit Parallel Form template from the Project settings. This option is not recommended, because usually both Master Endpoint and Auxiliary Endpoints are connected to the same Project and this way all Endpoints will inherit the same form template.

 
Below is an example of configured Master Endpoint with multiple available payment methods represented by Auxiliary Endpoints connected to it:
 
 
`Master Endpoint`
 
Below is an example of a successful transaction via the Master Endpoint. When Payer opened the Parallel Form, master transaction initiated an auxiliary transaction for the payment method selected on the form. Once the auxiliary transaction received final sucessful status, it triggered final successful status on the master transaction:
 
 
`Master Endpoint Transaction Example`

#### Payment Page Display Logic

Payment Cashier transactions can be initiated with API requests or via Virtual Terminal on UI. When Connecting Party (merchant or payment facilitator which represents merchant) sends a request to Master Endpoint, the Payneteasy system returns Parallel Form URL, HTML content of which is defined on the Master Endpoint level. When payment method is selected on Parallel Form, Payneteasy system returns HTML content of this payment method form template specified on the respective Auxiliary Endpoint level (or displays external payment form instead).
 
Each payment method has its own payment page display logic. Payment Cashier might have multiple transactions initiated within the same payment session, because it can have multiple payment methods available for the Payer. When Payer selects payment tab appropriate auxiliary transaction is initiated.
 
```plantuml
  skinparam ConditionEndStyle hline
  : (1) Initiate transaction;
  if ((2) Additional Payer input required?) then (yes)
  : (3) return input form;
  : (4) submit form;
  else (no)
  endif
  if ((5) External form required?) then (yes)
  : (6) request external form from the payment provider;
  : (7) redirect to external form;
  : (8) submit form on payment provider side;
  else (no)
  endif
  : (9) show wait form;
  : (10) process transaction;
  : (11) show finish form or redirect \nto Connecting Party website;
```

(1) Transactions can be initiated with API requests, batch upload or via Virtual terminal on UI. Each payment method has its own payment page display logic.
 

> **Note:** Payment Cashier might have multiple transactions initiated within the same payment session, because it can have multiple payment methods available for the Payer. When Payer selects payment tab, respective auxiliary transaction is initiated.

(3) For credit card payment method form is displayed on Payment Gateway side and can be customized. See Payment Page Customization. Some other payment methods may have additional forms on Payment Gateway side. Contact support for details.
 
(7) Some payment methods require the Payer to be redirected to their own form. That form is not hosted by Payment Gateway and can\`t be customized.
 
(9) Until transaction reaches final status, Payment Gateway displays Wait Form for the Payer.
 
(11) After the transaction reaches the final status, Payment Gateway displays Finish Form for the Payer or Redirect to Connecting Party website.
 

> **Note:** For all templates and macros for customization see [Forms Customization](https://doc.payneteasy.com/integration/reference/forms_customization.html.md)

### Performance Report

This report displays the financial flow for the specified period. It also allows to view the number of successful and unsuccessful transactions. Flexible criteria setting allows to get the needed data: date range and type, currencies, card types, grouping of data.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Preview of the report can be viewed by clicking on the Preview button.
 
The Report can be generated by clicking on the the Generate button.
 
An example of the resulting report is shown below:

### Processing Limits

#### Processing Limits

Hard & soft limits and cumulative processing limits can be found at Tools-Processing limits. This screen contains all previously configured default and country limits separated by tabs.

 

Main features:

> • Visualization
> • Flexible settings
> • Multicurrency
> • Alerting by e-mail
> • Warning limits (several thresholds)
> • Stop limit
> • Forecast for daily and monthly limits in the context of one period
> • Trend for daily limits in the context of several days

The limit can be found by its ID or name. Multiple limits can be found using search criteria. Search criteria can be saved as a template for future use. The list of created limits can be sorted by their ID. (Last created, First created)

`filter processinglimits`

#### Setting Up A New Limit

##### Default limits

Set up a new limit by pressing “+Default limit”:

New limit can be set up with several parameters:

• Manager
• Transaction type
• User defined - сan be Total, 3-D Secure, Not 3-D Secure or Payout.
• Additional criteria:

- Endpoint - after selecting endpoint it’s not possible to select Merchant;
- Merchant - after selecting Merchant it’s not possible to select endpoint;
- Gate - after selecting gate it’s not possible to select processor;
- Processor - after selecting processor it’s not possible to select gate;
- Company (group of gates);
- Card types.

• Time period:

- Daily/Weekly/Monthly/Hourly - date-dependent parameter. Monthly – limits refresh on the first day of every month. Weekly - limits refresh every Monday. Daily - limits refresh at every 00:00. Hourly - limits refresh at every hour;
- Time shift. Not supported at the moment, will be added later.

• Calculation:

- Value to summarize - can be set by transaction amount or transaction count;
- Currency to sum up - the currency for limit calculation must be specified;
- Consider currencies (optional field) - transactions in which currencies will be included in limit calculation;
- Suspend traffic - just yes or no. What to do with transactions when limit reached: stop traffic or not;
- Limit value - For Amount enter total transaction amount or transaction count for this limit. Limit doesn’t include settled value, if limit should be 15000 for it to be included value must be 15000.01. Range to make the limit amount less transparent.

##### Limits by country

Limits by country are available under separate “Countries” tab.

`default and country tabs`

Switch to the countries tab and set up a new limit by pressing “+Countries limit”:

`processinglimits countries limits`

New limit can be set up with several parameters:

`processinglimits countries limits screen`
• Manager
• User defined - сan be Total, 3-D Secure, Not 3-D Secure.
• Countries
• Additional criteria:

- Gate - after selecting gate it’s not possible to select processor;
- Processor - after selecting processor it’s not possible to select gate;
- Card types.

• Time period:

- Daily/Weekly/Monthly/Hourly - date-dependent parameter. Monthly – limits refresh on the first day of every month. Weekly - limits refresh every Monday. Daily - limits refresh at every 00:00. Hourly - limits refresh at every hour;
- Time shift. Not supported at the moment, will be added later.

• Calculation

- Value to summarize - can be set by transaction amount or transaction count;
- Currency to sum up - the currency for limit calculation must be specified;
- Consider currencies (optional field) - transactions in which currencies will be included in limit calculation;
- Suspend traffic - just yes or no. What to do with transactions when limit reached: stop traffic or not;
- Limit value - For Amount enter total transaction amount or transaction count for this limit. Limit doesn’t include settled value, if limit should be 15000 for it to be included value must be 15000.01. Range to make the limit amount less transparent

##### Warnings and Notification

Also, it’s possible to set different warnings for limits by choosing Limits reached percentage:

- Warnings when limit reaches 50%, 75%, 95%, 100% and for traffic suspension with notifications by e-mail and Telegram to address specified in user account ;

It is possible to add comment for limits by adding text in comment box

 
> `comment processinglimits`

Comment can be found at Tools-Processing limits page

 
> `comment example processinglimits`

### Chain Strategy Details

Chain strategy details allows to select which Declines (negative processing results) will continue or stop the chain.

If the configured routing has such balancing types as: Chain by Sequence, Chain by Equivalently on Tx Count, Chain by Coefficient on Tx Count, it’s possible to go to the “Chain
Strategy Details” tab on the gate level and select the criteria to continue or stop the chain.

> `processor_Chain Strategy Details`

The number and name of the processor is at the top of the page.
The active line “Continue the chain” is located below and the choice of criteria is to the right of it.
“Independently of the decline reason” is selected by default.

Two active columns – “Unavailable” and “Available” – are located below.
The reasons for decline are located in the “Unavailable” field.
The chain can continue:

> - Independently of the decline reason - the chain will continue regardless of the received decline codes.
> - Only for the selected decline reasons - the chain will continue only for the specified decline reasons. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button. Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button.
> Confirm the parameters with the “Save” button.
> - For any decline reason except the selected ones - the chain will continue for all reasons, EXCEPT for the specified ones. Select the reasons from the “Unavailable” column with the check boxes next to them, and add them to the “Available” column by clicking the “Add” button.
> Remove the unwanted reasons by selecting them with the check boxes and clicking the “Remove” button. Confirm the parameters with the “Save” button.

### Processor Detailed Report

Displays earnings details grouped by processor.
 
If necessary, you can add additional criteria by clicking the Criteria: endpoints, projects, merchants, gates, processors, etc. The customized search criteria can be saved as a template for later use.
 
Data can be downloaded by pressing the Generate button.
 
An example of the resulting report is shown below:

### Processor error codes

Processor error codes provides the ability for managers to designate a selected error as a [Perilous decline](https://doc.payneteasy.com/manager/tools/monitoring/tasks_man.html.md). If one of the chosen as perilous decline codes is received from the processor:
 
1. The corresponding notification will appear on [monitoring process](https://doc.payneteasy.com/manager/tools/monitoring/tasks_man.html.md) screen.
 
2. The corresponding marker will be attached to transaction and will be displayed on [Order Details](https://doc.payneteasy.com/manager/manager_orders.html.md) screen.
 
 
`processor error codes`

### Processor

**Processor Overview**
 
Processor is a Payment Gateway internal entity, which encapsulates interconnection with third-party processing system (e.g. Acquirer). The Processor list screen is located at Settings -> Configuration -> Processors. This screen contains all Processors created in the system.
 
 

**Processor Settings**
 

| [Processor Error Codes](https://doc.payneteasy.com/manager/processor/processor_errors.html.md) | This screen shows how to use processor error codes. |
|----------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------|
| [Processor Details](https://doc.payneteasy.com/manager/processor/processordetails.html.md) | This screen shows all parameters and details about the processor. |
| [Processor Acquirer restrictions](https://doc.payneteasy.com/manager/processor/processoracquirerrestrictions.html.md) | Configurable sets of rules which allow to restrict the traffic by certain criteria. |
| [Processor Chain Strategy Details](https://doc.payneteasy.com/manager/processor/processor_chainstrategydetails.html.md) | This screen shows information about additional cascading chains setup. |

### Processor Acquirer restrictions

This functionality allows to prevent non-successful processing of transactions on all gates of the same processor which have specific limitations. To switch them on, go to the required processor and click on the “Acquirer restrictions” tab. Tab will be available only for manager account and linked superiors.

> `Processor ACQ tab`
There are such restrictions as:
 
 

| Restriction Name | Comment | UI code and reason |
|----------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Whitelist check (WL) | Allows ignoring all other Acquirer restrictions for selected Source credit card numbers and Device fingerprints. Sometimes customer’s behavior can lead to the unfortunate situation where a shopper is completely unable to process transactions. You can whitelist a customer’s data so they can successfully process their transaction. White list could be specified for the exact Source card number by manager and the exact Device fingerprint by manager. | |
| Predefined loyalty lists check | Allows processing for trusted customers only. Different acquirers have different definitions of a trusted customer, this filter allows processing for customers with emails, source/destination card or purpose in corresponding loyalty lists only. Transactions for customers that are not listed in any loyalty list will be filtered out. | 18042 18043 18110 18111 |
| Destination Credit Card type check | This referral list allows to block transactions processing for selected Destination Credit Card types (Business, Corporate, etc.) | 18112 |
| Source Credit Card type check | This referral list allows to block transactions processing for selected Source Credit Card types (Business, Corporate, etc.) | 18113 |
| Source Credit Card external check | This verification process enables external inquiries to confirm if the source credit card is available for deposits | 18114 |
| Destination Credit Card external check | This verification process enables external inquiries to confirm if the destination credit card is available for withdrawals | 18115 |
| Check client approve count for merchant | This check fires when the number of transactions associated with exact client for that merchant does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 18116 |
| Check client approve count for manager | This check fires when the number of transactions associated with exact client for that manager does not reach the configured thresholds. The client can be identified by card or email address. Counts Sale, Preauth or Transfer transactions in the approved status. | 18117 |
| Customer name differs from Cardholder name | This check fires when the provided customer name does not match cardholder name. | 18120 |
| Customer billing address Country differs from Issuing Country | This risk check is triggered when a transaction has the customer billing address country different from the issuing country of the card. | 18121 |
| Processor lockout by specified declines | The filter allows locking out a Processor for Lockout period of time based on the defined Limit of declined transactions with the specific Analyzed decline codes occured for the Analyzed period of time. | 19100 |
| Billing Country blacklist | The filter allows blocking chosen countries | 19104 |
| Check client approve date for manager | This check fires if the client’s date since their first approved transaction is below the required number of days. The client will be identified by client definition set on endpoint/project level where endpoint overrides project setting. Counts Preauth, Sale, Transfer, Payout transactions in the approved status. | 19103 |
| Source Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. Timeframe can be set to calendar day instead of 24 hours window. | 18004 - Approved hourly amount limit reached 18005 - Approved hourly quantity limit reached |
| Source Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18002 - Approved weekly amount limit reached 18003 - Approved weekly quantity limit reached |
| Source Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18000 - Approved monthly amount limit reached 18001 - Approved monthly quantity limit reached |
| Destination Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions only in the approved status. | 18032 - Destination approved hourly amount limit reached 18033 - Destination approved hourly quantity limit reached |
| Destination Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions only in the approved status. | 18030 - Destination approved weekly amount limit reached 18031 - Destination approved weekly quantity limit reached |
| Destination Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions only in the approved status. | 18028 - Destination approved monthly amount limit reached 18029 - Destination approved monthly quantity limit reached |
| Total Credit Card Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18038 - Total approved hourly amount limit reached 18039 - Total approved hourly quantity limit reached |
| Total Credit Card Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18036 - Total approved weekly amount limit reached 18037 - Total approved weekly quantity limit reached |
| Total Credit Card Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact credit card number used as Source or Destination exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18034 - Total approved monthly amount limit reached 18035 - Total approved monthly quantity limit reached |
| Email usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18010 - E-mail approved hourly amount limit reached 18011 - E-mail approved hourly quantity limit reached |
| Email usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18008 - E-mail approved weekly amount limit reached 18009 - E-mail approved weekly quantity limit reached |
| Email usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18006 - E-mail approved monthly amount limit reached 18007 - E-mail approved monthly quantity limit reached |
| Email usage lifetime | Allows to limit the number and amount of transactions available to an individual customer and set a limit on the processor for the ALL time of existence. Customer is determined by E-Mail. This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time period is lifetime. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction. Counts Sale, Preauth or Transfer transactions in the approved status. | 18048 - E-mail approved lifetime amount limit reached 18049 - E-mail approved lifetime quantity limit reached |
| Customer IP usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18022 - Customer IP approved hourly amount limit reached 18023 - Customer IP approved hourly quantity limit reached |
| Customer IP usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18020 - Customer IP approved weekly amount limit reached 18021 - Customer IP approved weekly quantity limit reached |
| Customer IP usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Customer IP address exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18018 - Customer IP approved monthly amount limit reached 18019 - Customer IP approved monthly quantity limit reached |
| Purpose usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18016 - Purpose approved hourly amount limit reached 18017 - Purpose approved hourly quantity limit reached |
| Purpose usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in the approved status. | 18014 - Purpose approved weekly amount limit reached 18015 - Purpose approved weekly quantity limit reached |
| Purpose usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18012 - Purpose approved monthly amount limit reached 18013 - Purpose approved monthly quantity limit reached |
| Preventing transaction with the same amount | This check fires when more than one transaction is made with same amount in a time threshold (in seconds). The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the second transaction with the same amount during set time threshold. Counts Sale, Preauth, Payouts or Transfer transactions. | 18052 - Same amount request on processor |
| Issuer country usage frequency | This check fires when the number of transactions associated with the same card issuer country exceeds the configured thresholds. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18053 - Transactions quantity limit exceeds by country on processor |
| BIN range usage frequency | This check fires when the number of transactions associated with the specific card BIN range exceeds the configured thresholds, also can specify a list of card BIN range exceptions for which checks will not be performed. The maximum time threshold is a 300 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 300 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18056 - Transaction quantity limit exceeds by BIN range on processor |
| Transaction number per period | This check fires when the number of transactions exceeds the configured thresholds. The maximum time threshold is a 600 seconds window, calculated backwards from the moment of the first transaction. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction during 600 seconds. Counts Sale, Preauth, Payouts or Transfer transactions. | 18057 - Detected transaction in the set threshold of time |
| Source Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18054 - Daily decline quantity limit exceeded for the same credit card number on processor 18055 - Daily decline amount limit exceeded for the same credit card number on processor |
| Source Credit Card Number decline frequency for last 7 days (decline weekly limit) | This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 18058 - Weekly decline quantity limit exceeded for the same credit card number on processor 18059 - Weekly decline amount limit exceeded for the same credit card number on processor |
| Source Credit Card Number decline frequency for last month (decline monthly limit) | This check fires when the number of declined transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth or Transfer transactions in the approved status. | 18060 - Monthly decline quantity limit exceeded for the same credit card number on processor 18061 - Monthly decline amount limit exceeded for the same credit card number on processor |
| Account Number usage frequency for last 24 hours (daily limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 18062 18063 |
| Account Number usage frequency for last 7 days (weekly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 18064 18065 |
| Account Number usage frequency for last month (monthly limit) | This check fires when the number or amount of transactions associated with exact Account number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Sale, Preauth, Payout or Transfer transactions in the approved status. | 18066 18067 |
| Destination Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Transfer transactions in the Declined status. | 18068 - Daily decline amount limit exceeded for the recipient on processor 18069 - Daily decline quantity limit exceeded for the recipient on processor |
| Destination Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Transfer transactions in the Declined status. | 18070 - Weekly decline amount limit exceeded for the recipient on processor 18071 - Weekly decline quantity limit exceeded for the recipient on processor |
| Destination Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Transfer transactions in the Declined status. | 18072 - Monthly decline amount limit exceeded for the recipient on processor 18073 - Monthly decline quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last 24 hours (daily decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18074 - Daily decline total amount limit exceeded for the sender on processor 18075 - Daily decline total quantity limit exceeded for the sender on processor 18076 - Daily decline total amount limit exceeded for the recipient on processor 18077 - Daily decline total quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last week (weekly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a 7 days window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 168 hours. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18078 - Weekly decline total amount limit exceeded for the sender on processor 18079 - Weekly decline total quantity limit exceeded for the sender on processor 18080 - Weekly decline total amount limit exceeded for the recipient on processor 18081 - Weekly decline total quantity limit exceeded for the recipient on processor |
| Total Credit Card Number decline frequency for last month (monthly decline limit) | This check fires when the number or amount of declined transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a one month window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in one month. Month calculation based on calendar i.e. 28th, 29th, 30th and 31st of March would be bumped to 28th of February during window calculation. Counts Account verification, Sale, Preauth or Transfer transactions in the Declined status. | 18082 - Monthly decline total amount limit exceeded for the sender on processor 18083 - Monthly decline total quantity limit exceeded for the sender on processor 18084 - Monthly decline total amount limit exceeded for the recipient on processor 18085 - Monthly decline total quantity limit exceeded for the recipient on processor |
| Source Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18086 - Approved specified period amount limit reached 18087 - Approved specified period quantity limit reached |
| Destination Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Transfer transactions in the approved status. | 18088 - Approved specified period amount limit reached, 18089 - Approved specified period quantity limit reached |
| Total Credit Card Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Source or Destination credit card number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18090 - Total specified period amount limit reached 18091 - Total specified period quantity limit reached 18092 - Total specified period amount limit reached for recipient 18093 - Total specified period quantity limit reached for recipient |
| Purpose usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Purpose exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18094 - Purpose approved specified period amount limit reached 18095 - Purpose approved specified period quantity limit reached |
| Email usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18096 - E-mail approved specified period amount limit reached 18097 - E-mail approved specified period quantity limit reached |
| IP address usage frequency for last N days | This check fires when the number or amount of transactions associated with exact IP address exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18098 - IP address approved specified period amount limit reached 18099 - IP address approved specified period quantity limit reached |
| Fingerprint usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Fingerprint exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18100 - Fingerprint approved specified period amount limit reached, 18101 - Fingerprint approved specified period quantity limit reached |
| Account Number usage frequency for last N days | This check fires when the number or amount of transactions associated with exact Account Number exceeds the configured thresholds. The time threshold is a N days window calculated backwards from the moment of the transaction. The N parameter (date period) can be set from 1 to 30. For window calculation all transaction dates are truncated to days. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in N days. Counts Sale, Preauth or Transfer transactions in the approved status. | 18102 - Specified period amount limit exceeded for account number on processor 18103 - Specified period quantity limit exceeded for account number on processor |
| Declined Email usage frequency for last 24 hours (decline daily limit) | This check fires when the number or amount of transactions associated with exact Email address exceeds the configured thresholds. The time threshold is a 24 hours window calculated backwards from the moment of the transaction. For window calculation all transaction dates are truncated to hours. The risk fires on the transaction after the set threshold. So, if you set a threshold of 10 transactions, it fires on the 11th transaction in 24 hours. Counts Sale, Preauth or Transfer transactions in declined status. | 19101 - E-mail decline hourly amount limit reached 19102 - E-mail decline hourly quantity limit reached |

Below is the example of configuration for “Email usage frequency for last month (monthly limit)” restriction.
To switch this restriction on, click on the toggle button near it’s name:

> `emailusage balancing 2.0`

This restriction supports the following settings:

> 1. The Amount limit maximum total transactions amount for the last one month for this e-mail address. Value: total amount value.
> 2. For all gates with the same descriptor – current total transactions amount or count for the last one month for this e-mail address value would be calculated and converted to current gate currency to compare with amount or quantity limit. Specify the value “Y” (Yes) instead of “N” (No) to enable. Values: Y: for all gates with the same descriptor, N: for current gate only.
> 3. The quantity limit parameter specifies the transactions quantity limits. Value: total quantity value.
> 4. Use calendar month : Value: Y/N.

The choice of “Country Identifier” will be available in the “Deny” restriction configurations.

Each country is assigned its own numerical identifier. The required country can be chosen from the list.

### Processor Details

| Parameter Name | Description |
|---------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Status | Shows whether processor is enabled or disabled. |
| Created | Shows the exact date and time of processor creation. |
| Description | Shows processor description. Possible to edit after creating the processor. Please contact support team in order to change description. |
| Tags | Shows the tag of the processor. While searching processor by tag, all processors with the same tag will be shown. Possible to edit after creating the processor. Please contact support team in order to change tag. |
| Spring bean id | Shows under which Spring bean id the processor is. Represents processor logic for internal use by Payment Gateway support team. |
| Processor Group Id | Shows under which group id the processor is for internal use by Payment Gateway support team. |
| Type | General processing logic (e.g. CC) |
| Default card type | Shows default card type on the processor. |
| Code | Short code for processor. Possible to edit after creating the processor. Please contact support team in order to change code. |
| Dealer | Shows which Dealer is connected to the processor. Not possible to add Dealer after creating the processor. |
| Filter by blacklist | Allowing blacklist filter on processor level. |
| Transaction Types | Sale, Sale 3D, Reversal, Auth, Auth 3D, Capture, Cancel, Refund, Void, Chargeback, Chargeback Reversal, Prearbitration, Arbitration, Retrieval, Fraud, Pan Eligibility, Payout Cancel, CUP Payout. If transaction type has marker YES that means that processor can process these transaction types, if it has marker NO that means that processor cannot process them. If some type of transaction should be added or activated please contact support team. |
| MPI | Shows if MPI is on processor’s side or not. |
| Close Day | Shows if close day function is available on processor. |

### Project

**Project Overview**
 
 
Project is a Payment Gateway entity which determines the conditions for receiving a payment message and its further routing to the connected Processor. The Project list screen is located at Settings -> Configuration -> Projects. This screen contains all Projects created for all Merchants in the system.
 
 

 
- Project is enabled.
 
- Project is disabled.
 
 
To monitor the Project activity, Key Performance Indicators (KPI) are used, such as: Merchant earnings, Average order value, and others. The KPI submenu opens by pressing the Detailed button on the Project search screen. See details in [KPIs Detailed View](https://doc.payneteasy.com/manager/reference/kpi.html.md).
 
Click on the Project name to open detailed information about this project.
 
To work with other configuration options, see the information below.
 
 
**Project Settings**
 
 

| [Create, Clone, Edit Project](https://doc.payneteasy.com/manager/project/projectcreate.html.md) | This screen shows how to create and edit the project. |
|---------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Message Templates](https://doc.payneteasy.com/manager/project/projectmessage.html.md) | Shows all information about message templates sent to Customers after transactions. |
| [Project Details](https://doc.payneteasy.com/manager/project/projectdetails.html.md) | Project details screen contains information about configured options on this Project, its ID and limits. |
| [Routing & Balancing](https://doc.payneteasy.com/manager/project/routingandbalancing.html.md) | The routing & balancing system allows to distribute traffic between payment gates flexibly depending on the defined criteria and customer’s transaction data. |
| [Fraud protection filters](https://doc.payneteasy.com/manager/project/fraudprotectionfilters.html.md) | All information about filters. |

### Create, Clone, Edit Project

#### Project Creation

 
To create Project go to Settings -> Configuration -> Projects and press + Project in the top right corner.
 
 

#### Project Editing And Cloning

 
Press Edit button to edit project and Clone button to clone project.
 
 

 
Select new name and currency.
 
 

 
Click on Gate and select which gates to clone together with the project, then select new names for these gates.
 
 

 
Click on Endpoint and select which endpoints to clone together with the project, then select new names and which merchant will be assigned for these endpoints.
 
 

> **Note:** If no specific merchants are selected, the previously set merchant will be applied to all new endpoints by default.

 
Click on Other Settings to select whether to convert currency and copy all available filters on new entities or reset them to default.
 
 

 
To see which changes will be applied to cloned entity, press changes button.

### Project Details

| Parameter Name | Description | Necessity for creation |
|-------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------|
| Status | Shows whether Project is enabled or disabled. Can be changed later. | Required |
| Manager | Shows to which exact manager this project is linked. CANNOT be changed later. | Required |
| Manager rate plan | Allows to set manager rate plan. Can be changed later. | Required |
| Description | Shows Project description. Can be changed later. | Optional |
| Reseller rate plan | Allows to set reseller rate plan if reseller is selected. Can be changed later. | Optional |
| Payment form template | Allows to add payment form which will be displayed after initiating the transaction. | Optional |
| Wait form template | Allows to add wait form which will be displayed until transaction reaches the final status. | Optional |
| Finish form template | Allows to add finish form which will be displayed after transaction reaches the final status. | Optional |
| Tags | Shows the tag of the Project. While searching Projects by tag, all Project with the same tag will be shown. Can be changed later. | Optional |
| Loyalty service | Shows which external loyalty service is selected. Can be changed later. | Optional |
| Min transaction amount | Possible to set any minimal amount which be passed through the project. Can be changed later. | Optional |
| Max transaction amount | Possible to set any maximum amount which be passed through the project. Can be changed later. | Optional |
| Enable auto capture | Enables automatic capture. | Optional |
| Auto capture period (hours) | Sets the time in hours, after which preauthorized amount will be automatically captured. | Optional |
| Message server | Allows to select message server. | Optional |
| Returning customer approve sessions count | Shows after how many transactions with final status approved, customer will be considered as returning for the project. | Optional |
| Client definition | Shows by which criteria customer will be counted as new or returning for the project. | Optional |

#### Hold Pre-auth until capture settings

This section allows you to configure limits for preauth transactions before capture stage. Once the set limits are reached, subsequent preauth transactions are automatically held in processing status.

#### Operating mode

The Operating mode defines the scope of the limits. You can choose between PROJECT and MERCHANT.

* PROJECT - Limits are calculated across the entire project.
* MERCHANT - Limits are applied individually per merchant.

#### Preauth live time, quantity limit, amount

Preauth live time - The duration (in hours) after which the blocking period expires. Once this time passes, new pre-auth transactions will resume processing normally.
 
 
Quantity limit - The maximum number of preauth transactions allowed to pass. Once reached, new transactions will enter processing status until manually declined or the limit resets.
 
 
Amount - The maximum total volume (sum) of preauth transactions allowed. Any transaction that causes the amount to exceed this value will remain in processing status.
 

> **Note:** All the transaction that surpassed limit will receive status after limit duration passes.

### Message Templates

Message templates can be used to send SMS or E-mail messages to customer after each successful transaction. Merchant must provide their message server credentials to Payneteasy support manager in order to send such messages from merchant address. Templates are created using the Template button. After pressing it, a window with new template details will open:
 
 

 

The created template will appear in the list:

Message sending is enabled.
 
Message sending is disabled.
 
 

> **Note:** After cloning the project, Message Templates will need to be created manually again for the cloned project.

### Rate Plans

> **Warning:** Add page

### Reference

### Reports

Payneteasy has several reporting formats for cashflow and performance view, reconciliation and usage in external systems, as well as the ability to flexibly configure data that is displayed in reports. This section covers in detail the functionality of the system for display and download of reports in Excel and CSV format.

Payneteasy UI allows to generate the following types of reports:

| [Cashflow Report](https://doc.payneteasy.com/manager/reports/cashflow_report.html.md) | Calculates sales, manager turnover, returns, chargebacks, holds. Shows distribution of turnover by tariffs. Shows profit for the period and broken down by days. |
|---------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| [Transaction Report](https://doc.payneteasy.com/manager/reports/transaction_report.html.md) | List of transactions for a specific period of time. This type of report is most suitable in cases where it is necessary to reconcile transactions with the bank. |
| [Merchant Cashflow Report](https://doc.payneteasy.com/manager/reports/merchant_cashflow_report.html.md) | Calculates the turnovers and profits of the merchant date-by-date. |
| [Performance report](https://doc.payneteasy.com/manager/reports/performance_report.html.md) | Calculates the quantity and total volume of approved and declined transactions, reversals, chargebacks, transactions to which the fraud marker was applied, and the percentage of all unsuccessful financial transactions (declined, reversal, chargeback, fraud) in relation to approved transactions. |
| [Merchant Daily Performance Report](https://doc.payneteasy.com/manager/reports/merchant_daily_performance_report.html.md) | This report allows to generate a summary date-by-date list of transactions with the following types: sale, reversal and chargeback. |
| [Decline Statistics](https://doc.payneteasy.com/manager/reports/decline_statistics.html.md) | Displays statistics on rejected transactions, divided into the following groups: rejected by the acquiring banks, rejected by Payneteasy internal fraud system and rejected due to various errors in processing, should this occur. |
| [Fraud/Chargeback Ratio Report](https://doc.payneteasy.com/manager/reports/fraud_chargeback_ratio_report.html.md) | The chargeback ratio calculates the indicators of negative statistics for the merchant’s terminals. |
| [Fraud/Chargeback Reasons Report](https://doc.payneteasy.com/manager/reports/fraud_chargeback_reasons_report.html.md) | Builds a report on merchant chargeback reasons. |
| [Gate Details Report](https://doc.payneteasy.com/manager/reports/gate_details_report.html.md) | The report displays detailed information about the amounts of transactions in the context of payment gateways. |
| [Processor Detailed Report](https://doc.payneteasy.com/manager/reports/processor_detailed_report.html.md) | The report displays earnings details grouped by processor. |
| [Close Day Report](https://doc.payneteasy.com/manager/reports/close_day_report.html.md) | The report on closing days displays the exact time when the settlement day was closed at the gateways. |
| [Statements](https://doc.payneteasy.com/manager/reports/statements.html.md) | The integrated system that calculates statements per merchant and indicates which exact amount should be received from the bank for each statement date. Alternative approach to merchant balance calculation. |

### Request Endpoint Statistics

Managers are able to monitor requests to Endpoints by getting this statistical table:

 

 

All parameters of this screen are described below:

| Parameter Name | Description |
|------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ID | Endpoint identification number. |
| ENDPOINT NAME | The name of the Endpoint that used as an entry point for incoming Merchant’s transactions for single currency integration. Clicking on the name of the endpoint redirects user to the Integration Panel https://gate.payneteasy.eu/paynet-ui/tools/integration-panel with the selected endpoint. Available for Request endpoint statistics. |
| REQUEST COUNT | Total number of incoming requests. |
| ERROR COUNT | Total number of errors. |
| HTTP ERROR COUNT | Total number of http errors only. |
| LAST ERROR | Field that shows the last error occurred. |

### Request Group Statistics

Managers are able to monitor requests to Endpoint Groups by getting this statistical table:

 

 

All parameters of this screen are described below:

| Parameter Name | Description |
|---------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| ID | Endpoint group identification number. |
| ENDPOINT GROUP NAME | The name of the Endpoint group that used as an entry point for incoming Merchant’s transactions for multi currency integration. Clicking on the name of the endpoint group redirects user to the Integration Panel https://gate.payneteasy.eu/paynet-ui/tools/integration-panel with the selected endpoint. Available for Request group statistics. |
| REQUEST COUNT | Total number of incoming requests. |
| ERROR COUNT | Total number of errors. |
| HTTP ERROR COUNT | Total number of http errors only. |
| LAST ERROR | Field that shows the last error occurred. |

### Resellers

#### Creating Reseller

To see and search all Resellers, go to Settings -> Users -> Resellers, then in order to create new Reseller press to + New Reseller button:

Below are all the fields available for filling in:

| Field name | Description | Necessity |
|---------------|-------------------------------------------------------------------------------------------------------------------------------|-------------|
| Login | Login which is required while logging in the system. Cannot be changed after creation. | Required |
| Password | Password for login. In order to change it, contact support. | Required |
| Display Name | Reseller name which will be displayed. Can be changed after creation. | Required |
| E-mail | Contact E-mail which will be added to this Reseller account. Can be changed after creation. | Required |
| Control Key | Secret key which will be used for signing requests. Can be changed after creation. | Required |
| Payment group | Currently not in use. “Common” is a default value. Cannot be changed after creation. | Required |
| Name | Shows Reseller’s contact person name. This name will be displayed only in Reseller details. Can be changed after creation. | Required |
| Surname | Shows Reseller’s contact person surname. This name will be displayed only in Reseller details. Can be changed after creation. | Required |
| Logo | The logo of Reseller. Can be changed after creation. | Optional |
| Organization | Shows Reseller’s organization name. Can be changed after creation. | Optional |
| Tags | Shows tags by which Reseller can be found later in system. Can be changed after creation. | Optional |

### Routing & Balancing

#### General Information

The routing & balancing system allows to distribute traffic between payment gates flexibly depending on the defined criteria and customer’s transaction data.
Traffic can be routed to a specific group of gates/processors and distributed between them in accordance with the specified balancing.
The balancing is configured on the system Project level in the Routing & Balancing tab.

 

One of routing types must be selected to start the configuration:

New routing block will be created. Each routing block has it’s own ID for easier navigation in big projects.
The Source Card Type routing type is taken as an example:

Hover the cursor over the name of this block to select one of the following actions:

> - Add routing row - to add options for this block:

Select the card types from the provided list:

- Delete node - to select another routing or balancing block instead of this one.
 

Hover the cursor over the any criterion of this block to select one of the following actions:

- Continue Routing - to select new routing block and continue the routing strategy.

- Add balancing - to stop the routing and add the balancing block.

- to enable, disable or delete the routing option.

The default option named OTHERS is always present, it applies for transactions which don’t match all other created options.

If the created routing options are enough, click the Add balancing button to add one of the balancing types with the payment gates.

The Balance by coefficient Based on Tx Amount is taken as an example:

Blocks are connected by arrows to improve the visual presentation. An arrow is directed from a certain routing option to the block created from it.
If the transaction parameters match the specified routing option, it is forwarded further along the arrow.

Hover the cursor over the name of this block to select one of the following actions:

- Add balancing row - adds the row with active fields to specify the gate:

> - Payment gate - the longest field is used to select one of the available payment gates.
> - Probability percentage - far left field. This percentage determines how likely the transaction is to go to this gate. This field exists only for balancing types with a specified coefficient.
> - Three empty fields at the bottom are used to redefine the payment rates.
- Delete node - to select another routing or balancing block instead of this one.

- Create group - to create a group of the balancing.

Select a group of the balancing from the provided list:

If the transaction meets the created route conditions, it will be forwarded to the balancing block with this payment gate.
For more routing criteria, click the Add routing row of the required criterion, then create the subsequent transaction path from it. New block appears to the right of the selected criterion with a new number and routing type name.

 

The Source Card BIN routing type is taken as an example:

There is already an “OTHERS” default criterion below. As in the first case, click the Add routing row to add the appropriate criterion.
Depending on the required routing strategy and the traffic separation level, go on building the routes or finish the route by adding one of the Balancing types and clicking Add balancing row to add the payment gate. The final configuration might look as the following:

 

 

> **Note:** See the information below to check which types of [routing](#routing-types) and [balancing](#balancing-types) are available and which [Additional Configurations](#additional-configuration) can be applied.

After the Routing & Balancing configuration is set, enable it by going to the “Project” menu, clicking the “Edit” button and selecting the “Use new balancing” check box at the bottom of the page.
To confirm the selection, click “Update”.

Now, the Routing & Balancing is applied and all the traffic will go through it.

#### Routing Types

Several “routing types” are used in the Routing & Balancing to configure the transaction routes more flexibly.

Routing types are filters which allow to specify the traffic separation. Depending on the selected routing type, the transaction flow will be checked in relation to its parameters.

In the Routing & Balancing such routing types are represented as follows:

##### Source Card

> 1. The Source Card Type routing type allows to sort transactions by the sender’s card type. Select the appropriate payment methods of the sender and build a further route based on them.

> > 
 
> 2) The Card Range routing type allows to sort transactions by the sender’s card BIN value. Specify bin and choose the needed BIN range of the sender and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority.
> There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the BINs - button.

> > `card range balancing 2.0`
 
> `choose bins src balancing 2.0`
 
> `choose bins src balancing 2.0`
 
> 3) The Source Card Bank routing type allows to sort transactions by the sender’s Issuer Bank name. Select the needed names of sender’s Issuer Banks and build a further route based on them.
> There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.

> > 

> > 
> 1. The Source Card Country routing type allows to sort transactions by the sender’s card Country. Select the needed countries of the sender and build a further route based on them.

> > 
> 1. The Source Card Credit Source routing type allows to sort transactions by the sender’s card type. Select the needed card types of the sender and build a further route based on them.

> `sccs balancing 2.0`

##### Destination Card

> 1. The Destination Card Type routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.

> > 
 
> 2) The Card Range routing type allows to sort transactions by the receiver’s card BIN value. Specify bin and choose the needed BIN range of the receiver and build a further route based on it. Several BIN ranges can be found for the specified BIN value. Select the one with lower priority.
> There is an option to search cards by their BINs. System can search for up to 500 entered card BINs listed one after another and separated by commas. They can be chosen by pressing the “BINs -” button.

> > `card range dest balancing 2.0`
 
> `choose bins dest balancing 2.0`
 
> `choose bins dest balancing 2.0`
 
> 3) The Destination Card Bank routing type allows to sort transactions by the receiver’s Issuer Bank name. Select the needed Issuer Bank names of the receiver and build a further route based on them.
> There is an option to search Banks by their names. System can search for up to 500 entered Bank names listed one after another and separated by commas. They can be chosen by pressing the “By name -” button.

> > 

> 1. The Destination Card Country routing type allows to sort transactions by the receiver’s card country. Select the required card countries of the receiver and build a further route based on them.

> > 
 
> 1. The Destination Card Credit Source routing type allows to sort transactions by the receiver’s card type. Select the needed card types of the receiver and build a further route based on them.

> `rccs balancing 2.0`

##### Customer

> 1. The Customer Account Number Country routing type allows to sort transactions by connecting selected countries to one provider, and the remaining countries connecting to another. This routing type is used for payout transactions. Country and bank are determined by IBAN (International Bank Account Number), which has been generated in accordance with [ISO 13616](https://www.iso.org/standard/81090.html).

> `pic61_new balancing 2.0`
> 1. The Customer IP Country routing type allows to sort transactions by the IP address of the customer’s country. Select the countries, the IPs of which will be checked and build a further route based on them.

> > 
> 1. The Customer IP Range routing type allows to sort transactions which IP address values are within the specified range. Specify the appropriate IP range and build the further route from it. Both IPv4 and IPv6 are accepted.

> > 
> 1. Customer Billing Country routing type allows to sort transactions by the country from the customer’s billing address. Select the needed countries and build a further route based on them.

> > 
> 1. Customer Loyalty routing type is divided into endpoint, project, merchant, manager. Each of these levels has a Returning customer approve sessions count field that can be set for Managers by users with Superior role, while for Projects, Endpoints and Merchants - by users with Manager role. This value sets the number of transactions after which the customer will be considered “RETURNING”.

> > > By default, the Customer is defined by card. Definition is possible by card number, email, card holder and email, card holder and purpose, card holder and phone. Transaction count begins when definition is modified (each definition type stores its respective transaction count). The client definition is set in respective Client definition field on the Project level or Endpoint level (Endpoint setting overrides Project setting).

> > > Summary:

> > > - RETURNING_FOR_MANAGER - approve count on Manager level, Customer definition on Project/Endpoint level.
> > > - RETURNING_FOR_MERCHANT - approve count on Merchant level, Customer definition on Project/Endpoint level.
> > > - RETURNING_FOR_ENDPOINT - approve count on Endpoint level, Customer definition on Project/Endpoint level.
> > > - RETURNING_FOR_PROJECT - approve count on Project level, Customer definition on Project/Endpoint level.
> > 

> > The routing logic is checked sequentially, so the transaction goes through the first route that satisfies the condition.

> > For example the following route will first check the merchant loyalty and then the manager.

> > 
> 1. The CMS Trust Level routing type allows to sort transactions by the customer’s trust status recorded in CMS (Customer Management System). Select the needed trust levels and build a further route based on them. This routing type is only available for merchants connected to CMS.

> > > CMS Trust Level reflects whether the customer has previously completed an approved transaction, and takes one of three values:

> > > - CONFIRMED_FOR_MANAGER - the customer has an approved transaction on at least one project among the merchants of the same manager that share the same client definition value and have Automatic level change (auto-leveling) enabled.
> > > - CONFIRMED_FOR_MERCHANT - the customer has an approved transaction on at least one project of the current merchant that shares the same client definition value.
> > > - OTHERS - neither of the above conditions is met.
> > 

> > This value is not driven by a configurable approve-sessions-count field — a single approved transaction is enough to move the customer out of OTHERS, and the value is calculated automatically from the customer’s transaction history in CMS. It is also shown as the Cms Trust Level field on the order details page and in the transaction dump report.
> 1. by Recurring and Non_recurring routing types allows to sort transactions based on whether transaction type is recurrent or not.

> > 
> 1. by purpose routing type allows to sort transactions based on purpose. It is possible to enter more than one purpose value to each routing row. New values are added using the Add button which is available when editing or creating. Purpose limited to 128 symbols.

> View:

> > `purpose value 2.0`

> Edit:

> `purpose value edit 2.0`
> 1. by Phone IMEI (IMEI or International Mobile Equipment Identity) — this is the individual number of the mobile equipment. It is possible to enter more than one IMEI value to each routing row. IMEI limited to 32 symbols.

> View:

> `phone imei 2.0`

> Edit:

> `phone imei edit 2.0`
> 1. by Customer Instance routing type allows to sort transactions based on Customer payment history for the whole instance. Please contact tech Support manager to enable this functionality.

> Select the Customer type for instance and build a further route based on them.
> The client is defined as NEW or RETURNING based on criteria set on the Project level (by default) or Endpoint level (if specified).
> This option is called Client definition.
> Definition is possible by card number, email, card holder and email, card holder and purpose, card holder and phone.

> > `customerinstance 1.0`

> #### NOTE
> This option should only be used together with internal KYC procedures as it checks for existing payment history and doesn’t count any negative activity.

> 1. by Customer site url routing type allows to sort transactions based on customer’s site URL. It is possible to enter more than one site url value to each routing row. Site URL is limited to 128 symbols.

> View:

> `routing by site URL`

> Edit:

> `routing by site URL edit`

> **Note:** The Customer Site URL routing type does not account for formatting differences. The URL in the initial request must exactly match the URL specified in the routing node.

##### Transaction

> 1. Transaction Amount routing type allows to sort transactions by their amounts. The number in the square bracket is included in the range and the number in the round bracket is not included in the range. For example, to specify amount from 0 to 100 (including 100), use [0, 100.01). Transactions, which amounts match the specified range, will pass through this routing criterion.

> > `amount balancing 2.0`
> 1. Transaction Type routing type allows to sort transactions by their type. Select the needed transaction types and build a further route based on them.

> > 
> 1. Amount Multiplicity routing type allows to sort transactions by their amounts matching with specified multipliers. Add amount multiplicity and transaction will route by the highest amount to which it is a multiple. Example: If transaction amount is 1000 and “Amount multiplicity” is settled as 1000 and 500, transaction will route to 1000, and if transaction amount is 1500 it will route to 500, and if transaction amount is 2000 it will route to 1000.

> > `multiplicity balancing 2.0`
> 1. Transaction Time routing type allows to sort transactions by the time they are created in the system. Timezone GMT+3. This sort type can be used for processor technical breaks or for any other reason when time is necessary for any route. To set the time, for example, from 22:00 till 06:00, set the time the following way: [22:00:00, 23:59:59], [00:00:00, 06:00:00].

> `time balancing 2.0`
> 1. Day of week routing type allows to sort transactions by day of the week. Select the needed day of the week and time zone for further route based on them.

> > `Day of week 2.0`

##### Transfer

> 1. Transfer Direction routing type allows to sort transfer transactions by card types or Issuer banks of sender and receiver. Select the needed parameters and build a further route based on them.

> > 

##### IP Intelligence

> **Warning:** If Fraud Service - “Max Mind IP check service” is selected on project level, then regardless of whether “fraud filters” or “routing&balancing” are set up - all requests will be sent to Max Mind.

 
> 1. Anonymous vpn routing type allows to check when Payer IP address is considered as anonymous vpn by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `anonymous_vpn`
> 1. Anonymous IP address routing type allows to check when Payer IP address is considered as anonymous by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `anonymous_ip_address`
> 1. Hosting provider routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `hosting_provider`
> 1. Public proxy routing type allows to check when Payer IP address belongs to a public proxy considered by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `public_proxy`
> 1. Residential proxy routing type allows to check when Payer IP address belongs to a hosting or VPN provider considered by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `residential_proxy`
> 1. Tor exit node routing type allows to check when Payer IP address is Tor exit node considered by Max Mind service. YES - if condition is true, NO - if condition is false. Select the needed parameters and build a further route based on them.

> > `tor_exit_node`
> 1. Static IP score routing type allows to check when Payer IP address Static IP score which is considered by Max Mind service is lower or equal to the settled threshold value. Higher values mean a greater static association. For example, many IP addresses with a user type of cellular have a score under one. Broadband IPs that don’t change very often typically have a score above thirty. This indicator can be useful for deciding whether an IP address represents the same user over time. The value ranges from 0 to 99.99. Select the needed parameters and build a further route based on them.

> > `static_ip_score`
> 1. User count routing type allows to check when Payer IP address user count considered by Max Mind service is higher or equal to the settled threshold value. The estimated number of users sharing the IP/network during the past 24 hours. For IPv4, the count is for the individual IP. For IPv6, the count is for the /64 network. Select the needed parameters and build a further route based on them.

> > `user_count`

#### Balancing Types

Balancing type is a feature which allows to distribute transactions between payment gates in accordance with the configured parameters.

> **Note:** The gate can also be specified directly on the endpoint. However, it will still be subject to the routing strategy, but will be selected for all transactions coming from this endpoint on this route.

The following balancing types are presented in the system:

##### Balance By Coefficient

> 1. Balance by coefficient Based on Tx Amount allows to sort transactions by the gates depending on the amount and the specified probability percentage.

> > 

> For example, 3 gates have 20%, 30% and 50% coefficients set for them.
> In this case, 50% of the first several processed transactions will be forwarded to the gate with the probability of 50%, then the traffic will try to reach the distribution of the amount between the gates in accordance with the specified percentages.
> If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal to the percentages set for the gates.

> 1. Balance by coefficient Based on Tx Count allows to sort transactions by gates depending on their quantity and the specified probability percentage.

> > 

> For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, 50% of the processed transactions will be forwarded to the gate with the probability of 50%.
> The transaction amounts are not considered, only their quantity is.

##### Balance Equally

> 1. Balance equally Based on Tx Amount allows to sort transactions by gates depending on the amount with equal probability percentage.

> > 

> If there are e.g. 4 gates, “Balance equally on Tx Amount” will set an equal probability percentage of 25% for each gate. The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution of the amount between the gates.
> If the processed amount on a gate exceeds the amounts on the other gates, the transactions will not be forwarded to the gate with the exceeding amount until the amounts on all the gates become equal.

> 1. Balance equally Based on Tx Count allows to sort transactions by gates depending on the quantity with equal probability percentage.

> > 

> If there are e.g. 4 gates, “Balance equally on Tx Count” will set an equal probability percentage of 25% for each gate.
> The first several transactions can be forwarded to any of them as the percentages are equal, then the traffic will try to reach the equal distribution between the gates based on the quantity of transactions.

##### Cascading Chain

> 1. Chain by Coefficient Based on Tx Count allows to sort transactions by gates using the specified probability percentage and the chain principle. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones according to their coefficients.

> > 

> For example, 3 gates have 20%, 30% and 50% coefficients set for them. In this case, the gate with 50% coefficient has the 50% probability of becoming the first gate in the formed chain.
> If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain. If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it.
> The traffic will try to reach the distribution between the gates according to their coefficients based on the quantity of transactions.

> 1. Chain by Equivalently Based on Tx Count allows to sort transactions by gates using the chain principle and an equal probability percentage. If the incoming transaction is going to be filtered or exceed the limits on some gates, the balancing algorithm excludes these gates and then it forms the chain with the remaining ones based on equal probability percentage.

> > 

> If there are e.g. 4 gates, “Chain by equivalently on Tx Count” will set an equal probability percentage of 25% for each gate.
> In this case, each gate has the 25% probability of becoming the first gate in the formed chain.
> If for some reason the first gate in chain was unable to process the transaction, it goes to the next gate in chain.
> If the second gate was not able to process the transaction as well, it moves on until one of the subsequent gates in chain processes it.
> The traffic will try to reach the equal distribution between the gates based on the quantity of transactions.

> 1. Chain by Sequence allows to sort transactions using the cascading chain principle.

> > 

> Transactions will be processed by gates only in a priority order.
> If for some reason the first gate in the chain was not able to process the transaction, it moves further along the chain until one of the subsequent gates in chain processes it.
> The gate priority can be changed in “Chain by Sequence” using drag’n’drop.

> 1. Chain by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status and the chain principle.

> > 

> All client transactions (defined by email) are checked within the exact processor (not among all of them) and the next transaction is routed to the gate with last successful transaction of this client. If attempt on this gate was declined, transaction moves further along the chain until one of the subsequent gates in chain processes it.

##### Others

> > 1. First in Sequence allows to sort transactions by choosing the first appropriate gate for them.

> > > 

> > If the incoming transaction is going to be filtered or exceed the limits on certain gates, the “First in Sequence” algorithm excludes these gates and then it sends the transaction to the highest gate of the remaining ones.
> > The gate priority can be changed by dragging it up and down.

> > 1. First in Sequence by Last Customer Tx Status on Acquirer allows to sort transactions by resulting transaction status.

> > > 

> > All client (by e-mail) transactions for all projects are checked and the next transaction is routed to the gate with processor of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Also, all gates belonging to the same processor as the gate on which the rejection status occurred receive low priority.
> > Gate with processor with last approved transaction will be first in sequence, a gate with processor with earlier approves or no approves will be last.

> > 1. First in Sequence by Last Customer Tx Status on Gate allows to sort transactions by resulting transaction status.

> > 

> > All client (by e-mail) transactions are checked and the next transaction is routed to the gate of the last successful transaction project-wide. If a transaction is in declined status, gate is moved to the bottom of the sequence and receives lowest priority. Unlike First in Sequence by Last Customer Tx Status on Acquirer balancing type, the gates belonging to the same processor as the gate on which the declined status occurred do not lose priority and do not fall at the end of the sequence.
> > Gate with last approved transaction will be first in sequence, a gate with earlier approves or no approves will be last.
> 1. First in Sequence with Approval Overrides allows to sort transactions by how the client’s last transaction performed on each acquirer.

> > 

> > The strategy distributes transactions across gates based on how the client’s last transaction performed on each acquirer: if the last transaction on an acquirer was approved, that acquirer gets priority for the client’s next transaction; if it was declined, the acquirer’s priority is lowered and the next acquirer in the sequence is used instead. This effect fades over time — the longer since the last transaction, the smaller its influence on gate priority.

#### Additional Configurations

##### Gate Skips

The gates in the balancing block can be skipped for processing of the transaction in the following cases:

> 1.) If [Acquirer restrictions](https://doc.payneteasy.com/manager/gate/acquirerrestrictions.html.md) on gate level is triggered;

> 2.) For Cascading chain options - if the decline message specified in [Chain Strategy Details](https://doc.payneteasy.com/manager/gate/chainstrategydetails.html.md) or [Chain Strategy Skips](https://doc.payneteasy.com/manager/gate/chainstrategyskips.html.md) is received, the chain will stop;

> 3.) If the gate is disabled on the gate level;

> 4.) If the gate is disabled in balancing block;

> 5.) If gate is set to be ignored, because it’s intended only for direct processing from specific Endpoints (see [Ignore Gates For Direct Processing](#ignoring-gates) below).

##### Ignore Gates For Direct Processing

Ignoring gates - ignores selected gate for whole node.
|
If it is needed to use gate, but only for the specific Endpoint without any changes in the routing, use Ignoring gates, so that way this gate will be ignored for the rest of the traffic and will only be used with the specific Endpoint.
|

`pic11 balancing 3.0`

##### Rates

Rates is a system of payment fees for all stakeholders’ services.

The system supports such stakeholders as:

Merchant, Reseller, Manager, Dealer, Bank.

In the current model, the fees are incrementally increasing, from the Bank to the Merchant.
The following rate plan will count the value of the previous one. Thus, the higher the participant’s level is, the greater his total fee is in the system. The Bank and Dealer rate plans can be set on the gate level. Manager, Reseller, and Merchant rate plans can be set on the project level, with the option to override them on the endpoint level.
The presence of some participants in the payment rates model is optional.

In Routing & Balancing the Rates can be redefined directly on the gates configuration in balancing blocks.
These Rates settings override the ones on project or endpoint level.

There are 3 active fields below at the gate’s name, which are responsible for redefining rate plans for Manager, Reseller and Merchant, from left to right respectively.
All rate plans can be selected from the dropdown list of already created ones.

##### Copy, Paste, Cut, Delete

Routing & balancing nodes can be deleted, along with all children:

Each deletion requires confirmation:

Fragments of balancing tree can also be cut and pasted:

Choose where to paste the cut fragment:

Result:

Parts of a balancing tree can be copied in a similar way as well:

Tap on Copy node.

Choose where to paste the copied fragment:

Result:

The same process can be repeated for the last part of the balancing tree:

Result:

##### Import And Export

You can import and export your balancing tree:

Balancing tree file is generated in xml and has the following structure:

```http
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<strategy>
    <projectId>4947</projectId>
    <projectDisplayName>Recur AUD</projectDisplayName>
    <routingNodes>
    <routingNode>
            <id>8572</id>
            <routingId>1</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23277</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8573</nextRoutingNodeId>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
            </routes>
            <root>true</root>
        </routingNode>
        <routingNode>
            <id>8573</id>
            <routingId>2</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23279</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8574</nextRoutingNodeId>
                    <others>false</others>
                    <criteria>
                        <criterion>
                            <entityId>8104</entityId>
                            <entityName>213100</entityName>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
                <route>
                    <id>23278</id>
                    <enabled>true</enabled>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>1</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
        <routingNode>
            <id>8574</id>
            <routingId>3</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23281</id>
                    <enabled>true</enabled>
                    <nextRoutingNodeId>8575</nextRoutingNodeId>
                    <others>false</others>
                    <criteria>
                        <criterion>
                            <entityId>1825</entityId>
                            <entityName>DEMO BANK</entityName>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
                <route>
                    <id>23280</id>
                    <enabled>true</enabled>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>1</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
        <routingNode>
            <id>8575</id>
            <routingId>4</routingId>
            <enabled>true</enabled>
            <routes>
                <route>
                    <id>23282</id>
                    <enabled>true</enabled>
                    <balancingNodeId>8750</balancingNodeId>
                    <others>true</others>
                    <criteria>
                        <criterion>
                            <value>OTHERS</value>
                        </criterion>
                    </criteria>
                    <order>0</order>
                </route>
            </routes>
            <root>false</root>
        </routingNode>
    </routingNodes>
    <balancingNodes>
        <balancingNode>
            <id>8750</id>
            <enabled>true</enabled>
            <balancingId>1</balancingId>
            <rows>
                <row>
                    <id>0</id>
                    <enabled>false</enabled>
                </row>
            </rows>
        </balancingNode>
    </balancingNodes>
</strategy>
```

### Settings

### Settings Search

The screen is designed to find projects, endpoints and other entities by their name or ID and is located in “Settings” – “Settings Search” section.

 

The search range can be specified to endpoints, projects or other entities.

### Statements

#### Main Information

> `picbig statements_eng`

Payneteasy platform contains integrated calculation system to reflect the tariffication between business process partners. Calculation happens on each level, from dealer to merchant. Bank fees are calculated for tariffication and settlement, but statements for settlement with the bank are not provided by the system.
Instead, the system calculates statements per Merchant and indicates which exact amount should be received from the bank. Statement is individually generated for each manager or each merchant of this manager. Statement date is called business day. Statement for business day contains all projects for chosen manager.
Statements will be calculated for manager if such option is enabled. If statement should be calculated, enable the Default calculate statements flag in manager account details. If this option is not enabled, statements setting in projects of exact manager will be unavailable and statements are not calculated.

> `pic2 statements_eng`

Statements can be calculated manually or automatically. Automatic statements calculation starts every 2 hours. Statements menu also has options to create new statement or delete statement that already exists.

> **Note:** After deleting the statement, all information about payed and frozen amounts is lost forever. Only last business day can be deleted. Deleted statements must be recalculated sequentially from a lesser date to the next. Otherwise, if statements are recalculated by jumping over several dates, then intermediate business periods will be included in one.

`pic3 statements_eng`

Managers are able to count statements only for themselves and their merchants, superiors are also able to calculate statements for their managers.
Positive balances from previous months do not carry over. Negative balances are taken into account in the current period as a balance for the beginning of the period. A separate statement is generated for each currency. If the counterparty has projects in different currencies, then several statements will be generated for each currency.

#### Statements Calculation Parameters

The calculation of statements begins with the definition of a list of transactions, which are included in the specified business period. All transactions are conditionally divided into the following types:

1. Reducing the merchant’s balance (chargeback, reversal and etc.)
2. Increasing the merchant’s balance (sale, capture and etc.)

The system supports Hold mechanism to determine the list of positive transactions that will be included in statement and Delay mechanism to reduce risks in settlements with counterparties.

#### Delay

Delay — is a mechanism for short-term postponement of payments for positive transaction volumes, which allows to form a safety cushion equal to the average merchant’s turnover for the paid period. It allows to minimize the risks of negative activity during the merchant’s work.

> `pic4 statements_eng`

The payment strategy, its frequency and delay can be configured on endpoint level. The following strategies are supported:

1. daily payments, payment periods and delay are defined in days,
2. weekly payments, payment periods and delays are determined in weeks, statements are generated on Mondays,
3. monthly payments, payment periods and delays are determined in months, statements are generated on the first day of each month.

The start date of payment period, as well as any other derivative dates obtained during the formation of statements, can not be less than the endpoint registration date.

Payment **Period** determines the regularity of business days. For example, if the payment strategy is weekly, and the period is two, then the statements are generated every two weeks. The minimum period is one.

Payment **Delay** determines the number of periods for which the funds received for positive transactions will be delayed before they are paid to the counterparty. For example, if the statements are calculated monthly with a payment period once a month, then, if the delay period is set to one period, the merchant will receive money for positive transactions for the second-to-last month, instead of the last one. The merchant will be able to receive money for the last month only next month. Negative transactions accounted in the statement ignore the delay period to minimize risks.

Statements are calculated using the latest delay parameters configured at the endpoint. This allows to recalculate the statements for the previous business days using the new parameters.

#### Holding

Holding — is a mechanism for medium- and long-term postponement of payments for positive transaction volumes. It allows to form a safety cushion to repay negatives received after the end of the merchant’s work.

> `pic5 statements_eng`

The amount to be paid for positive transactions that is included to the statement may be partially withheld for periods comparable with dispute flow and fraud claims. Holding mechanisms are used for this purpose. Holding period and amount are specified in the rate plan. The hold period is set in days. The hold value is set in percent. It is not possible to change these values after calculating the rates for the processed transaction. Each transaction has a unique period and a holding percentage calculated on the date of its processing.

> `pic6 statements_eng`

When specifying the duration of the delay, please note that the holding period, specified in the rate plan during the carryover payment, does not include the payment delay period, specified in the endpoint settings. This is done in order to avoid holding payments until the main amount is paid, with a large delay in payments and a small delay in the hold. I.e., if the holding period for the transaction is one day for daily payments with a frequency of one day and a delay of three days, the carryover for the transaction will be paid in 4 days from the moment of its processing.

> `pic7 statements_eng`

#### Preliminary Review Of Future Statements

It is possible to view statements for future dates before they are generated, in order to be able to predict the necessary amounts to be paid on company accounts. The number of periods for which the preview is available is set in the user profile.

> `pic8 statements_eng`

The calculation of payment dates when generating the statement and its preview differs from each other. When calculating the preview dates, the delay parameters specified for the endpoint are strictly taken into account. When calculating dates during the scheduled formation of the statement, the start date of the business period is shifted to the end date of the last available business period. This feature is useful when generating statements that include several payment periods and when changing the payment period or delay. If the dates grid, obtained when calculating payment periods, differs from the actual payment dates (for example, when parameters for calculating statements are changed and statements the previous business days are not recalculated) the preview might not be available for a future date or the start dates of the period will be incorrect.

#### Statement Adjustments

Statements can take into account not only the transaction commission. The statement balance can be changed by means of adjustments that can be accrued for any counterparty from the dealer to the merchant.
Adjustments can be applied to the statement on a special screen in the menu “Reports” – “Statements” – “Adjustments”.

> `pic_cor statements_eng`

There are two types of adjustments:

1. earnings adjustment - certainly changes the client’s balance in the current statement by the full amount of the adjustment,
2. carryover adjustment-changes the amount of the paid carryover for the selected number of periods.

#### Earnings Adjustments

> `pic9 statements_eng`

The adjustment of earnings can both reduce the statement balance in case of fines, and increase it in case of erroneous billing. The statement takes into account adjustments whose date is less than the date of the statement formation, which were not taken into account in earlier statements. The adjustment can be initiated with the indication of the endpoint. In this case, it will be displayed in the details of the endpoint in the statement, changing its balance. If the endpoint is not specified, the adjustment will be listed in the statement header.
Statements for the merchant are generated on behalf of the reseller, if it is available on the project, for the reseller to manage the merchant’s statements. If there is no reseller, statements are generated directly from the manager. Similarly, an adjustment can be made for the merchant. If a reseller is selected when creating an adjustment, an extract will be generated on behalf of the reseller, indicating this adjustment. If the earnings adjustment is included in the statement, then it cannot be changed (except for the comment) or deleted.

#### Carryover Adjustments

> `pic10 statements_eng`

The second type of adjustments can only reduce the statement balance. Carryover adjustments, according to the name, are deducted from the paid hold. If an endpoint is specified when creating an adjustment, the adjustment will be deducted exclusively from the carryover of this endpoint. If the endpoint is not specified, the adjustment will reduce the entire available carryover of the merchant in exact statement.
Unlike earnings adjustments, carryover adjustments can be accounted for in multiple statements. The unaccounted part of the adjustment is transferred to the calculation in the next period. The maximum number of business days in which the adjustment should be taken into account is set by the “Max deduction periods”parameter. If this parameter is zero, the number of business days to be debited is assumed to be equal to infinity. The maximum amount of application of the carryover adjustment in the current billing period is limited to the maximum amount of the carryover, if the current number of statements in which this adjustment was taken into account does not exceed the “Max deduction periods”parameter. If this parameter is exceeded, the unaccounted amount of the adjustment is converted into an earnings adjustment. Creating positive carryover adjustments in the system is prohibited.

#### Statements Calculation Sequence

The statements are calculated in the following order:

1. the dealer’s statements are generated. First, the dealer’s statements are detailed by gates. Then the adjustments of the carryover paid to the dealer from the bank are applied. After that, earnings adjustments are calculated. The final balance of the current period is calculated as follows: to the difference between the bank and dealer cold, add the difference between the applied bank and dealer transaction commissions. In the final, the bank carryover is added minus the carryover adjustments and the carryover paid by the dealer is deducted.
2. the manager’s statements are generated, the manager’s statements are detailed by gates; adjustments are applied to the carryover paid to the manager from the dealer or the bank in his absence; earnings adjustments are calculated; the final balance of the current period is calculated as: the difference between the dealer (bank) and the manager’s hold add the difference between the applied dealer (bank) and manager transaction commissions; in the final, the dealer (bank) carryover is added minus the carryover adjustments and the carryover paid by the manager is deducted,
3. reseller statements are generated, reseller statements are detailed by endpoints; adjustments of the carryover paid to the reseller from the manager are applied; earnings adjustments are accrued; the final balance of the current period is calculated as: the differences of the manager’s and reseller’s hold add the difference of the applied manager’s and reseller’s transaction commissions; in the final, the manager’s carryover is added minus the carryover adjustments and the carryover paid by the reseller is deducted,
4. merchant statements are generated, merchant statements are detailed by terminals, indicating the reseller; adjustments are applied to the carryover paid to the merchant from the reseller or manager in his absence; earnings adjustments are accrued; the final balance of the current period is calculated as: the difference between the reseller (manager) and merchant transaction commissions applied; in the final, the reseller (manager) carryover is added minus the carryover adjustments and the amount of the merchant’s transactions excluding the amount of service operations and a Money Transfer type operation,
5. after the formation of statements for all counterparties are combined into statements for companies; statements for companies are detailed by merchant, reseller, dealer and manager, for the possibility of accounting for paid funds on the company’s balance sheet; of all the carryovers and holds, only the bank’s carryover and hold are taken into account in the company’s statements.

> `pic11 statements_eng`

The calculated balance of the current period for each type of user is added to its current balance. The balance is maintained individually for each currency. For merchants, the balance is also detailed by the reseller, if available. The company’s balance sheet is not taken into account.
The counterparty’s current balance is defined as the sum of the current balance of all its statements, minus paid and frozen funds.

> `pic12 statements_eng`

#### Viewing Statements

The statements are viewed in **“Reports” – “Statements”**. On this screen, statements can be sorted by currencies, merchants, resellers and dealers, as well as by the payment status (“All”, “Frozen”, “Not paid”) and date range.
Using the date range, you can select the date of the statement that you want to upload.

> `pic_statement_check statements_eng`

The statement can be downloaded in XLS or PDF formats. To download it, click on the name of the merchant and select the appropriate format icon.

> `pic_format statements_eng`

#### Freezing Of Payments

Frozen payment status in the advanced search can be used to manage statements for which payments have been suspended. The mechanism for freezing payments is used in cases of detecting suspicious activity of the counterparty, or receiving information from the bank about the impossibility of making payments on the current statement for unspecified reasons for an indefinite period, until any disputed issues are resolved.
Frozen funds reduce the counterparty’s balance for payment. Frozen funds are managed within one business period. The amount of the frozen funds can not exceed the amount of payment of the current statement.

#### Making Payments

In order to minimize possible losses, relevant information is displayed in the payment window.

> `pic13 statements_eng`

After clicking on the amount to be paid, the first graphical component of the analytics panel is displayed, with the following conditions:

1. chart type-negatives,
2. date range: from the beginning of the period of positive transactions included in one of the previous statements to the current date, a total of at least 5 recent periods when paying for the last business day and more when paying for the previous business days
3. axes — sum, quantity,
4. advanced search — for everyone except the merchant: the traffic of all merchants that included in this statement; for the merchant-directly the merchant; all taking into account the currency,
5. the graph shows an interval that displays the period of positive transactions that included in this statement,
6. the following data is displayed for informational purposes. According to the current statement — the period of positive transactions, the amount of transactions of the sale (capture) type, the amount of transactions of the transfer type, the number of transactions of the service type, the held hold. Total — unpaid balance, amount paid, frozen balance. A list of all payouts with a comment is also displayed.

### Online Monitor

#### Overview

The screen is located in “Tools” – “Monitoring” section. This screen displays information about various errors that usually require quick response, as well as the options to subscribe for notifications about any errors via Telegram `icon_telegram` or Email `icon_email`. E-mail address are taken from the personal account (Manager or its employee account).

 

 

#### Perilous Decline

This section is located in [Overview](#manager-online-monitor). This section displays triggered perilous declines which were selected by Manager.
 
To create a list of perilous declines, use [Processor Error Codes screen](https://doc.payneteasy.com/manager/settings/configuration/processor/processor_errors.html.md).
 
If Perilous declines list is empty please contact with support.
 
 

#### Important Filters

Notifications can be created for cases in which transactions were filtered due to the one of the following filters:

| Field name | Description |
|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------|
| Date | The date when alert has been created. |
| ID | Alert identification number. |
| Name | Name of the Merchant. |
| MerchantID | Merchant identification number. |
| Error Description | Triggered project filter error description with error code. Example: [1033] Too many approved transactions for the same credit card number. |

### Tools

### Transaction Markers

Transaction markers are created to notify users about specific issues that might happen to transactions and usually require quick response or additional business process (for example, manual review or communication with the customer). This screen allows to view all created transaction markers and work with them, by adding comments to markers and set them as “processed” if the issue has been resolved.
Notifications about new markers can be sent by e-mail, this functionality is configured on “Transaction Marker Notification” screen.
Transaction markers can be sorted with search criteria by marker type and status. The list of markers contains information about each marker type, status and linked order ID:

### Transaction Marker Notification

#### Overview

The Transaction marker notification tool is used to notify users about specific issues that might happen to transactions and usually require quick response. Each time the specified transaction marker is triggered, it will send email notification to user’s email address. For example, if notifications for chargebacks are enabled, user will get a new email notification for each chargeback applied to a processed transaction. Email content can be customized.

The main screen displays a list of all notifications, their status, ID, subject, language, merchant name, message type and marker type.

#### Configuration

To add a new marker, press the Create button in the upper right corner. Notification configuration box will appear with the following parameters:
 
 

 

| Parameter | Description |
|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Status | Enabled/Disabled |
| Marker type: | * Chargeback * Chargeback after ethoca reversal * Chargeback after reversal * Duplicated chargeback * Failed cancels * Failed captures * Failed PAN eligibility * Failed payin session initiators * Failed payout session initiators * Failed reversals/refunds * Failed scorings * Fraud * Inconsistent order status * Incorrect decline code * Multiple master approvals * Phone verification * Processor callback notification * Refused payouts * Refused refunds * Retrieval * User defined |
| Merchant | To select a merchant, enter the name or ID of the merchant |
| Subject | All emails for this marker will have this subject |
| Message type | * Email - Email with plain text. * Email (HTML) - Email with HTML support. |
| Message | All emails for this marker will have this text message. Transaction Marker Notification supports [Message Templates](https://doc.payneteasy.com/integration/common_utilities/receipt_message.html.md). Additionally $!{MARKER_TYPE_NAME} was added. |

### Transaction Report

This report contains the list of transactions for the specified time period. To download the necessary data, the following criteria are used: dates, date type, transaction types, change status, card types, transaction id, recurrent filter, time zone, CSV encoding. This report can also be downloaded by API for automated reconciliation or analysis: [Remote transactions report](https://doc.payneteasy.com/integration/common_utilities/reports.html.md#remote-transactions-report). Additional criteria can be added by pressing the Criteria button: order status, currency, endpoints, projects, etc.
 
The maximum download period for report is 93 days, if data download for six months or more required, divide the required period into parts.
 
To change the template, use the template management tool:
 
 

 
Select criteria for this report in the following pop-up window:
 
 

 
After selecting the necessary parameters, enter name for the template and click on Save button. To download the report, click on the CSV button.
 
Example of the resulting table is shown below:
 
 

 

> **Note:** The returned report has wellformed CSV format. In accordance with [RFC 4180](https://datatracker.ietf.org/doc/html/rfc4180), fields containing line breaks (CRLF, CR, LF), double quotes, and commas are enclosed in double-quotes.

### Users

The Users screen is located at Settings -> Users. This screen allows to view, configure and create user accounts in the system. Each user account can have multiple linked employees.
 

| [Merchants](https://doc.payneteasy.com/manager/users/merchant.html.md) | This screen allows to create, configure and see all Merchant accounts created in system. |
|-----------------------------------------------|--------------------------------------------------------------------------------------------|
| [Resellers](https://doc.payneteasy.com/manager/users/reseller.html.md) | This screen allows to create, configure and see all Reseller accounts created in system. |

### Virtual Terminal

#### Overview

Virtual terminal (VT) is a technological solution that allows to process transactions from Merchant’s personal account on User Interface. This feature doesn’t require Merchant’s API integration to Payneteasy. VT immediately provides a full-featured payment manager’s workplace. VT is used for remote processing of transactions without the presence of a customer, for example, if the customer places an order or pays for services while being in another city or country. VT workflow is fully customizable in order to meet the business needs. Flexible templates will help to minimize time of filling all the customer details. The Virtual terminal supports recurring payments (by recurring ID). If the customer provided cardholder data to gate.payneteasy.eu processing system before, and the Merchant registered such payment to get recurring ID, future payments can be made with recurring ID instead of cardholder data. VT also allows to generate a link for the customer to submit cardholder data in the secure environment, and, if needed, pass 3-D Secure validation.
 
 
VT provides a secure way of processing MOTO transactions with support of asymmetric cryptography. In order to do so please, [Generate A Pair Of Public And Private Keys](#man-public-private-keys-vt) and then pass public key to Payneteasy support and upload the private key in Browser Console ([Import Private Key To Browser Console](#man-import-private-keys-to-bc-vt)) or User Interface ([Import Private Key To User Interface](#man-private-key-to-ui-vt)).
 
The available operations for VT are:
 
 
• accepting payments from both new and previously registered customers ([Sale](#man-sale-vt));
 
• hold funds from both new and previously registered customers ([Preauth](#man-preauth-vt));
 
• transfer of funds from card to card, both for new and previously registered customers ([C2C (Card To Card) Transfer](#man-transfer-vt));
 
• issuance of funds to the cards of both new and previously registered customers ([D2C (Deposit To Card) Transfer](#man-d2c-vt));
 
• transfer of funds from one bank account to another ([Payout](#man-payout-vt)).
 
 
The screen is located in Tools – Virtual terminal (VT).
 
 

#### Asymmetric Cryptography

The big advantage of the new Virtual terminal is the use of an asymmetric cryptography system. Asymmetric cryptography, or public-key cryptography, is a cryptographic system that uses pairs of keys: public keys which may be disseminated widely, and private keys which are known only to the owner. The generation of such keys depends on cryptographic algorithms based on mathematical problems to produce one-way functions. Effective security only requires keeping the private key private; the public key can be openly distributed without compromising security.
 
 
The Virtual terminal becomes personalized. The user signs transaction request with his private key and the system uses the public key to verify that request is made by the owner of the corresponding private key.
 

##### Generate A Pair Of Public And Private Keys

Virtual terminal requires a pair of public and private keys from user to authorize requests. To generate it, go to [https://www.openssl.org/](https://www.openssl.org/) ( [https://slproweb.com/products/Win32OpenSSL.html](https://slproweb.com/products/Win32OpenSSL.html) ), download the latest openssl version and run the following commands:
 
 
openssl genpkey -algorithm RSA -out private_key_pkcs_8.pem -pkeyopt rsa_keygen_bits:4096
 
 
openssl rsa -pubout -in private_key_pkcs_8.pem -out public_key.pem
 
 
Please, do not share private key with anyone, it is confidential information for private use only. In contrast, public key must be passed to Payneteasy for endpoint configuration. Please use different keys for production and testing environments to avoid compromise.
 
 
PKCS #8 RSA unencrypted private key in PEM format starts with —– BEGIN PRIVATE KEY —– text. This key must be imported to Browser Console or User Interface. See details below.
 

##### Import Private Key To Browser Console

Private key is imported into browser’s IndexedDB using a script associated with the currently opened page. This script only uses plain browser APIs (Web Crypt API, IndexedDB API) and does not use any external scripts to avoid the private key being compromised.
 
Import sequence is:
 
1. Open [https://gate.payneteasy.eu/paynet-ui/login-step1](https://gate.payneteasy.eu/paynet-ui/login-step1) page in a browser (Do not login to the system).
 
2. Open the browser console. In Chrome, it is done with Ctrl+Shift+J. In Safari, it is done with Ctrl+Shift+I, Ctrl+Alt+C. For Mac - Cmd instead of Ctrl.
 
3. Replace the demo key below with real private key in PEM format (it must have **—–BEGIN PRIVATE KEY—–** prefix in the beginning).
 
```http
var privateKeyPem = `-----BEGIN PRIVATE KEY-----\
     MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQDJzUVnqQhDWF2H
     pxAMcyo7f+ucIEJS3AQHG0ET/dxJ0qssGymIjdzelJ3XI+oTq2y9TTimQjtujoeh
     6zl44WrXCbJLCUDWsNjlh7hmBorpU6tJVhw1466CAxkktPJHkMqJYF0efegIfOwU
     otTzwY4tGlN6iWK0aMJ5ZWhWpZDbgap72vrRXKfCN6/JeTUdsOI7PAeZw0me04jZ
     8Lova9FVIbVzOJaFGwSUroMvXevIB8rOD57c3VCLTxE3aGNMz+9DLl6GCm8WZ1US
     HmiHybqgvGLyQswBPFcVzFgd7BpgZs+JAzYDh8ZGANvjA5F9u0b6Ynb3Mpm3+9Rl
     CtvSxKwpAgMBAAECggEAZ6+hro5KIZggjleHRm5Rz7p9S33DtiE3rJMTT/tKmV+1
     9XaLU49YYcDIjMb2OV8GAwnPRpWXRcnT5J0grXxc0do4kpdRij3ZY63lT/6ilxoX
     Uxn8aq/udPy0iYizR5QcjJNHpSgZ9WqCPmQfuJLFw2TYaYh3f6yn54n0Hzj4gd9l
     tsol4xeTKQ47c/vUF7kHfD8IYzL8jv3a3++IqzCwJ3jIpTENsBYAgrkbYN9f9GHD
     BvX3sz6tgFaYU2R8YbDvA0Yq9tVPwYrPvbhwoht6PsjE/R0UK6yqnKPEADdzWvP8
     frXmmtJ35rAymqUWfpqx9RdZ0NMR7J8ut8C5365PJQKBgQD+UidVWut7d9qvhZKq
     +T5qtasH5qkD34idFl4Ay8xsSntqTrXr7q1Ff+FQY6R+f/8IzB4ZqgnV58+8AEMc
     gJzNmkf9L119SCQDxRV/TgW2eHrUrI9XS2AI5tmyzaGY1xL4fCQQMvqNAGERT6sS
     XJRt8WjuGmE4zeqxNB0XY7u1OwKBgQDLIlnksOrPw00lWUbXHSHwdfBzjYU97KVu
     GnOl5fsCmlKanqHUfd/4StnRXpl3l56hig8mYsHV5EcfUEX98PaSbTAy8Lk5y5E9
     ye2ENOgl/IyMgHPtT6spFKm7jRmpulqG4FVCGxQl3n6/nSmztA3S1zLZzi0guI0E
     oxXCbG796wKBgC8NSgOrr5eHRClnIAyL0nVxqPPsQ+bYi3Dsu3WQPwDmAtFXQKcm
     4F3UW/5AgSV6Ttf007jR0cIGglN5BPGYBeqwGZOJGNXd6/PambCU4c+xmKASUO7I
     njrnYu2Gx9f8KqFYbl+k3uAJauwF/lOGV1vD5zLuJICa8Enap2s1Y3wTAoGBAKrx
     QnLISyIB+XbXtVyrYHdJ2Mp1Ks6cye5pBi9y5RQgqCkEG62FLCh3XOvrTvysNEs+
     slccPoBv9UYtuGjmEanRhwEnQMiZPaWgu2dJWp8081X9dxEavS/5+oghSpphf3MH
     b9gMj5z6qvE3IfPfLs7iWCGgdquVgt6HG3Wc6J53AoGAc+ZYE8kMj2p9rtu1uJgX
     +VMbbdLEUqz3BPC9Tzq+eglUlYmwUK1xynKZfkEMcu5PncaBaNLU+GmYKKgw6wZS
     soEF1KvbBB4o6nZdlGo0BirOQ0ijHDWUvtuiaaWAQoQAhQwgqqV2IOC4UfkZ6ORf
     A/UW43A9wZq9kaEgb0YWOes=\
     -----END PRIVATE KEY-----`;

// Algorithm Object
var algorithmKeyGen = {
  name: "RSASSA-PKCS1-v1_5",
  // RsaHashedKeyGenParams
  modulusLength: 2048,
  publicExponent: new Uint8Array([0x01, 0x00, 0x01]),  // Equivalent to 65537
  hash: {
    name: "SHA-256"
  }
};

function parsePem(pemString, type) {
    const expectedPrefix = "-----BEGIN " + type + "-----";
    const expectedPosftix = "-----END " + type + "-----";

    pemString = pemString.trim();
    if (!pemString.startsWith(expectedPrefix)) {
        throw "Expected PEM to start with " + expectedPrefix;
    }
    if (!pemString.endsWith(expectedPosftix)) {
        throw "Expected PEM to end with " + expectedPosftix;
    }
    const base64 = pemString.substring(expectedPrefix.length, pemString.length - expectedPosftix.length).trim();
    return Uint8Array.from(atob(base64), c => c.charCodeAt(0))
}

function parsePrivateKeyPem(pem) {
    return parsePem(pem, 'PRIVATE KEY')
}

function storePrivateKey(privateKey) {
    var request = indexedDB.open("keys");

    request.onupgradeneeded = function() {
      // The database did not previously exist, so create object stores and indexes.
      var db = request.result;
      var store = db.createObjectStore("privateKeys", {keyPath: "name"});

      // Populate with initial data.
      store.put({name: "first", key: privateKey});
    };

    request.onsuccess = function() {
      db = request.result;
    };
}

var privateKeyArray = parsePrivateKeyPem(privateKeyPem);
var NON_EXTRACTABLE = false;
window.crypto.subtle.importKey("pkcs8", privateKeyArray, algorithmKeyGen, NON_EXTRACTABLE, ['sign'])
.then(function(privateKey) {
        storePrivateKey(privateKey);
        privateKeyPem = null;
        privateKeyArray = null;
    }
);
```

4. Copy this script content and paste it into browser console.
 
5. The key has been imported in a non-extractable manner.
 
 

> **Warning:** If private key have been integrated into the browser, but it is impossible to make a transactions, please, clear browser’s cache and try again to integrate the private key.

 

> **Note:** If the proposed code is not suitable or if more information is required about the **Web Crypto API**, please visit the official site [https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Crypto_API).

##### Import Private Key To User Interface

The Virtual terminal has the function of using a private key through the user interface
 
 

 
In order to faster conduct a large number of test transactions, please check the “Save key in the browser” box, and the private key will be automatically saved in the browser.
 
 

#### VT Interface Details

The VT has control buttons, which are described in more details below.
 
 

#### Template Management

1) To simplify the work of the Virtual terminal operator, data fields can be saved as a template. Using templates allows to work only with the individual attributes of the client.
 
 

 
2) After entering data on the right side of the page, it is possible to save this data as a template by clicking ‘save as a template’ and naming the new template.
 
 

 
3) To edit, clone, delete or share, click three dots near the template name and select the desired parameter. The template can be shared with users at lower levels. This way, a merchant can share the template with their employees.
 
 

 
For all selected users, the created template will become the default upon loading the virtual terminal.
 
Changes can still be made before conducting a transaction, but only the creator of the template has the authority to modify the template itself. Users with whom the template has been shared are only allowed to make copies.
 
The number of created templates available for sharing is unlimited. They will all be displayed to users in alphabetical order.
 
 

#### Transaction Specification

##### Deposit

In the deposit section, it is possible to make a Sale and a Preauth transaction, which are described below.
 

###### Sale

Sale is a type of transaction, in which customer receives goods or services from Merchant in exchange for money or other assets.
 
To initiate transaction, submit the following 3 types of information:
 
1) Transaction data - Endpoint, amount, currency, description, invoice number must be filled directly on VT.
 
2) Card info - Cardholder, Card number, Valid thru:
 
- can be filled directly on VT;
 
- can be filled automatically together with Personal info, if Recurring ID is provided. If Recurring ID is provided and CVV field is empty, use “Copy link” to provide form to customer for additional confirmation. In case if it will be filled in VT form directly then transaction will be processed directly.
 
- can be filled by customer on the form.
 
3) Personal info - First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address ,Country, etc:
 
- can be filled directly on VT;
 
- can be filled automatically together with Card info, if Recurring ID is provided;
 
- can be filled automatically, if Customer ID is provided.
 
 
Process transaction:
 
- Use “Copy link” button to generate the payment link and send it to the customer. This flow is relevant for transactions which require additional information submitted by customer on the form (cardholder data, 3DS check, etc).
 
- Use “Process” button if transaction doesn’t require any additional information submitted by customer (e.g. noCVV non3D recurring transactions).
 
The image shows the options available for filling.
 
 

###### Preauth

Pre authorization is a transaction type in which bank blocks the specified amount in the customer’s card account and does not allow the cardholder to use this blocked money.
 
It is important to know that the block remains for a definite period of time depending on whether this is a debit or a credit card (usually the maximum block period is 7 days for debit cards and 28 days for credit cards).
 
To initiate transaction, submit the following 3 types of information:
 
1) Transaction data - Endpoint, amount, currency, description, invoice number must be filled directly on VT.
 
2) Card info - Cardholder, Card number, Valid thru:
 
- can be filled directly on VT;
 
- can be filled automatically together with Personal info, if Recurring ID is provided. If Recurring ID is provided and CVV field is empty, use “Copy link” to provide form to customer for additional confirmation. In case if it will be filled in VT form directly then transaction will be processed directly.
 
- can be filled by customer on the form.
 
3) Personal info - First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address ,Country, etc:
 
- can be filled directly on VT;
 
- can be filled automatically together with Card info, if Recurring ID is provided;
 
- can be filled automatically, if Customer ID is provided.
 
 
Process transaction:
 
- Use “Copy link” button to generate the payment link and send it to the customer. This flow is relevant for transactions which require additional information submitted by customer on the form (cardholder data, 3DS check, etc).
 
- Use “Process” button if transaction doesn’t require any additional information submitted by customer (e.g. noCVV non3D recurring transactions).
 
 
The image shows the options available for filling.
 
 

##### C2C (Card To Card) Transfer

Card-to-card transaction is a direct transfer of funds from card to card (C2C).
 
Several scenarios are possible:
 
1) Transfer money from unknown card to registered card.
 
Receiver data is retrieved using Destination Recurring ID. The receiver Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Country and other optional customer data) sections will be filled in automatically. To speed up the filling of recipient fields, use the Last used section next to “Destination recurring ID” field, which contains previously used Recurring IDs. The Merchant creates a special link for the sender with “Copy link” button. The sender receives the link to a form in which he fills his card number, expiration date, holder name and CVV, then passes the 3DS check if needed.
 
2) Transfer money from registered card to unknown card.
 
Sender data is retrieved using Recurring ID. The sender Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Customer IP-address, Country and other optional customer data) sections will be filled in automatically. CVV is not stored and must be requested from sender. To speed up the filling of sender fields, use the Last used section new to “Recurring ID” field, which contains previously used Recurring IDs. The Merchant creates a special link for the sender with “Copy link”. The sender receives the link to a form in which he fills the destination card number, then passes the 3DS check if needed.
 
3) Transfer money between known or registered cards.
 
The Merchant fills the cardholder data or use recurring IDs for both sender and receiver of funds directly on VT and initiates transfer processing with “Process” button. In this case the transaction must be processed through the non3D channel, which is not common for C2C transfers.
 
 

> **Note:** When filling in the Customer ID field, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.
 
 

##### Withdrawal

In the withdrawal section, it is possible to make a D2C (Deposit to card) transfer and a Payout, which are described below.
 

###### D2C (Deposit To Card) Transfer

A Deposit-to-Card transaction is a transfer of funds from a bank account to a payment card.
 
Several scenarios are possible:
 
1) Transfer money to known card.
 
The Merchant fills the cardholder data for receiver of funds directly on VT with “Process” button.
 
2) Transfer money to registered card.
 
Receiver data is retrieved using Destination Recurring ID. The receiver Card info (Cardholder, Card number, Valid thru) and Personal info (First name, Last name, City, Address, Zip code, Phone, E-mail, Country and other optional customer data) sections will be filled in automatically. To speed up the filling of recipient fields, use the Last used section next to “Destination recurring ID” field, which contains previously used Recurring IDs.
 
3) Transfer money to unknown card.
 
The Merchant creates a special link for the recipient of funds with “Copy link” button. The recipient receives the link to a form in which he fills the destination card number.
 
 

> **Note:** When filling in the Customer ID cell, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.
 
 

###### Payout

A Payout transaction is the disbursement of funds to a recipient account number, digital wallet or other type of account. The Merchant fills the payment data for receiver of funds directly on VT and initiates payout with “Process” button.
 
 

> **Note:** When filling in the Customer ID field, Personal info (First name, Last name,City, Address, Zip code, Phone, E-mail, Country) sections will be filled in automatically.

 
The image shows the options available for filling.
