Monitoring and performing payments

Restriction: This section describes the new interface Dashboard Light. To learn how to access this interface if you already use Dashboard, see Getting started.

Overview

Dashboard Light interface allows you to monitor payment processing as well as to issue refunds and perform payouts in the following sections:

  • Payments—a section for monitoring information on all payment types; not intended for performing payouts.
  • Manual payments—a section for monitoring and performing payouts.

In each of these sections, payment processing can be monitored in the consolidated register, with the possibility to filter data and view detailed payment information about individual payments. Detailed payment information is shown in separate tabs within the section which allows users to switch between the register and the tabs more efficiently.

Figure: Payments list in the Payments section



Dashboard Light supports two workflows for issuing refunds and performing payouts: you can send a one-time request to initiate one operation (namely, initiate a single refund/payout) and you can send a batch request to initiate an arbitrary number of operations (namely, initiate mass refunds/payouts). In the former case, everything is done via the interface: to initiate a refund or a payout, you fill in several fields and confirm sending the request. In the latter case, all parameters of the requests are specified in the file which is then uploaded to the interface. In both cases, however, regardless of the request format, refunds can be issued for the full payment amount or the part of it (if it is supported for the payment method used), and the card details for performing payouts can be specified either in the form of actual card credentials, or as a token.

Access to Payments and Manual Payments sections and their specific features is granted through a relevant set of permissions. Therefore, if any of the features described below is not available to a certain user, you need to verify whether the user account in question has the appropriate set of permissions. Moreover, in order to issue refunds and perform payouts, two-factor authentication is required for accessing Dashboard Light interface. Two-factor authentication is enabled and set up in the Security section of My profile.

The guidelines on how to monitor payment processing, issue refunds, and perform payouts as well as the overview of working with batch requests are provided below.

Monitoring payment processing

Payments and Payouts lists allow Dashboard Light users to monitor information about amounts, statuses, or other attributes of the processed payments. It can be done in the lists themselves with the use of standard filtering tools (learn more) and in the payment information tabs which specify details of individual payments and all operations initiated within them (to open the payment information tab, click the row of the payment you need in the Payments list).

Figure: Payment information tab

To monitor information about specific payments:

  1. Select the section you need: Payments or Manual payments.
  2. Find rows with the information about specific payments in the list. Use filters, if necessary.
  3. Verify the information you need, either in the list or in the payment information tabs.

However, when you work with payments and payouts lists, keep in mind the following:

  • Information in lists and payment information tabs is shown with a time lag which can take up to several minutes. In addition, automatic data refresh is not supported.
  • The number and the order of columns in the lists can be customised, which means that with the appropriate set of permissions the lists can be arranged according to individual needs.
  • Key attributes of payments which include identifier, type, status, amount, and currency are by default shown in the first columns of both lists. In Payments these attributes are used for filtering data with predefined filters, while in Manual payments predefined filters are used for filtering data by single and mass payouts and by their corresponding statuses.
  • The Amount field shows the payment's base amount to which the status of the said payment currently applies.

    For example, if a partial refund for 20 EUR was issued for the payment of 100 EUR, then the status partially refunded applies to the amount of 100 EUR, while the refund amount and the remaining amount are shown in the Refunded and Available for refund fields.

    Another example is a scheduled COF purchase. For this payment type, the Amount field shows the actual amount of the received funds.

If you have any questions about working with Payments and Payouts lists, contact your account manager.

Issuing refunds

Requirements

Dashboard Light interface allows users to issue full or partial refunds with the use of individual and batch requests. In both cases, the following requirements must be met:

  • Two-factor authentication is enabled for the Dashboard Light user account in question.
  • The user account has been granted the right to issue refunds.
  • The purchase to be refunded has been fully processed.
  • Refunds of the required type are supported for the payment method used to make the purchase.
  • The balance under which an initial payment was performed has enough funds for issuing a refund

If any issues regarding these requirements occur, they can be solved with the specialists in charge of granting access rights and working with balances.

Single refunds

To issue a single refund:

  1. If necessary, locate the purchase that needs to be refunded.

    You can use the Search function or go to Payments section and apply necessary filters in the lists.

  2. Open the payment information tab for the target purchase.

    Click the corresponding row in the list of the Payments section.

  3. Send a refund request.

    To achieve this:

    1. Click the Refund button located on the payment information panel.
    2. In the window that opens, specify the required refund amount (full available or its part).
    3. Confirm your request by clicking Refund.
    Note: If the Refund button is disabled, it may mean that the payment has not been fully processed yet; if it is absent, it may mean that issuing refunds by using requests is not supported for the selected payment method.
  4. Make sure that the refund has been issued.

    You can do this by checking the status of the operation in the payment information tab (it should state success) or the status of the payment in the Payments list (when the payment is refunded in full, the status is refunded or reversed; when only the part of the payment amount is returned, the status is partially refunded).

If the refund has been declined, the status of the operation switches to decline while the status of the payment remains unchanged. The decline can happen due to a variety of reasons. For example, it can be caused by the lack of funds, in which case you can add funds to the balance and try to issue a refund again.

Mass refunds

To issue multiple refunds using a batch request:

  1. Create and prepare the file with the refund data in the specified format.

    You can find the file requirements with the template and a file sample below.

    Note: When preparing the file, keep in mind that the payment_id field should contain the identifier of the payment to be refunded.
  2. Go to the Mass Refunds subsection.

    To achieve this, go to Manual payments, click Request on the left of the filtering panel and switch to Mass refunds tab.

  3. Upload the file with the list of refunds and check it for data consistency.

    You can either drag the file or use Browse button to upload.

    Following the validity check, either the Send request button is enabled or the error message is shown. In the latter case, you can view the details of the error (using the File preview toggle and then the File details button), correct the error and re-upload the file.

  4. Send the batch request by clicking Send request.
  5. Make sure the refunds have been processed.

    This information is shown in the notification that the request has been accepted. The batch status and the status of individual refunds can be also monitored as follows:

    • To check the batch status, click Mass requests on the filtering panel, find the row of the specific batch in the list, and check the values in the columns Count (which shows the number of sent requests) and Indicator (which shows the number of completed refunds and the number of refunds that failed).
    • To check the status of individual refunds, check the status of the payments that need to be refunded in the Payments list (they should have the status refunded or reversed when the payment is refunded in full and partially refunded when only the part of the payment amount is returned). You can also check the status of a refund in a corresponding payment information tab (it should state success or decline depending on the operation result).

If you have any questions about issuing refunds, contact your account manager.

Performing payouts

Requirements

Dashboard Light interface allows users to perform payouts with the use of individual and batch requests. In both cases, the following requirements must be met:

  • Two-factor authentication is enabled for the Dashboard Light user account in question.
  • The user account has been granted the right to perform payouts.
  • Payouts are supported for the selected payment method.
  • The balance under which payouts are performed has enough funds.

If any issues regarding these requirements occur, they can be solved with the specialists in charge of granting access rights and working with balances.

Single payouts

To perform a single payout:

  1. Go to Single payout subsection.

    To achieve this, go to Manual payments, click Request on the left of the filtering panel and switch to the Single payout tab.

  2. Send a payout request.
    To achieve this:
    1. Specify payout parameters.
      Keep in mind that:
      • The amount is entered as a decimal number with a point to separate fractional part (for example, 314.15).
      • Fields for the payment method specific parameters are not available until the project, the amount, the currency, and the payment method have been specified.
      • Among the specific fields only the required ones are shown (if it is necessary to specify optional parameters, for example payment.description, use mass payouts feature).
      • If the field is filled incorrectly, the error message "Specify payout parameters" is shown.
    2. Confirm payout request by clicking Send request
      Note: If the Send request button is disabled, it may mean that not all required parameters have been specified or errors have been detected.
  3. Make sure that the payout has been processed.

    The information about it is shown in the notification window. You can also check the status of a payout in the Payouts and Payments lists (it should state success).

If the payout is declined, the payment status switches to decline. It can happen due to a variety of reasons. For example, it can be caused by the lack of funds, in which case you can add funds to the balance and try to perform a payout again.

Mass payouts

To perform a series of payouts using a batch request:

  1. Create and prepare a file with the payout data in the specified format.

    You can find the file requirements with the template and a file sample below.

  2. Go to the Mass payouts subsection.

    To achieve this, go to Manual payments, click Request on the left of the filtering panel and switch to Mass payouts tab.

  3. Upload the file with the list of payouts and check it for data consistency.

    You can either drag the file or use Browse button to upload.

    Following the validity check, either the Send request button is enabled or the error message is shown. In the latter case, you can view the error details (using the File preview toggle and then the File details button), correct the error, and re-upload the file.

  4. Send the batch request by clicking Send request.
  5. Make sure the payouts have been processed.

    This information is shown in the notification that the request has been accepted. The batch status and the status of individual payouts can be also monitored as follows:

    • To check the batch status, click Mass requests on the filtering panel, find the row of the specific batch in the list, and check the values in the columns Count (which shows the number of sent requests) and Indicator (which shows the number of completed payouts and the number of payouts that were declined).
    • To check the status of individual payouts, go to Payouts and Payments lists (the status should state success or decline depending on the operation result).

If you have any questions about performing payouts, contact your account manager.

Mass payments data

File upload requirements

Each file used for performing mass payments must meet the following requirements:
  • The data files must be uploaded in CSV format and the character encoding must be UTF-8 without BOM (Byte Order Mark string).
  • The file size cannot exceed 128 MB.
  • The first row must contain the names of parameters. The order of parameters can be random.
  • The subsequent rows must contain values of target parameters. Specifying values for optional parameters is recommended but not required.
  • All parameter values in the file must meet the requirements provided in the table below.
  • If operation parameters are specified in strings (not in table format), parameter values in each row must be separated by a semicolon (";"). In addition, the fields without values are separated by semicolons in the same way as the fields with values, and two or more ";" characters can follow one another, for example:


    If you use Microsoft Excel to create and prepare the file, make sure that strings do not include incorrect or extra characters. You should use a different editor, for example Notepad, to check if extra characters have been added.

Parameters for mass payments

When adding data to files, you can use the parameters presented in the table below. For more information about these parameters, see the API specification.

Parameter Description

operation_type
string, required

Operation type. The value can be refund or payout.
Example: payout

general.project_id
integer, required

Project identifier assigned by ECommPay at the stage of integration.
Example: 35

method
string, required

Payment method identifier. For the full list, see IDs of payment methods supported in Dashboard Light.
Example: card

general.payment_id
string, required *

Payment identifier unique within the merchant's project.
A string which contains between 1 and 255 characters and which can include any letters, digits, and symbols in UTF-8 encoding.
Example: payment_536231.
* For refund, general.payment_id must be the identifier of the purchase to be refunded

payment.amount
integer, required

Payment amount in minor currency units.
An integer between 1 and 10000000000000 (without a decimal separator between the integer and fractional parts).
Example: 1905 for 19.05 and 190500 for 1905

payment.currency
string, required

Payment currency code in ISO 4217 alpha-3 format.
Example: EUR

payment.description
string, optional *

Payment description.
A string, must not exceed 255 characters.
Example: Deposit 12456.
* Required for refunds

account.number
string, optional

Account number of the customer.
A string, must contain between 1 and 100 characters.
Example: 1670033323

account.bank_id
integer, optional

Bank identifier received from ECommPay. For more information about banks and their IDs, see the section on payment methods in the documentation, or contact ECommPay technical support specialists.
An integer, must be 1 or greater.
Example: 421

account.customer_name
string, optional

First name and last name of the account holder.
A string, must contain 1 character or more.
Example: John Johnson

account.branch
string, optional

Name of the customer's bank branch.
A string, must not exceed 255 characters.
Example: Bank branch

account.city
string, optional

City of the bank branch location.
A string, must not exceed 255 characters.
Example: London

account.region_id
integer, optional

Region or state identifier of the bank branch location received from ECommPay. For more information about regions and their IDs, see the section on payment methods in the documentation, or contact ECommPay technical support specialists.
An integer, must be 1 or greater.
Example: 3

card.pan
integer, optional *

Card number of the customer.
An integer, must contain 32 digits or fewer.
Example: 2333776109871312.
* Required for payouts if token is not present

card.year
integer, optional *

Expiration year of the customer's card.
An integer between 2020 and 9999.
Example: 2024.
* Required for payouts

card.month
integer, optional *

Expiration month of the customer's card.
An integer between 1 and 12.
Example: 12.
* Required for payouts

card.card_holder
string, optional *

Name of the cardholder as specified on the card.
A string, must not exceed 255 characters.
Example: John Johnson.
* Required for payouts

token
string, optional *

Card token received from ECommPay.
Example: Z0yTL5shY8ddhpxdQyplRPJYmGV7Kv.
* Required for payouts if card.pan is not present

customer.id
string, optional *

Identifier of the customer within the merchant's project.
A string, must not exceed 255 characters.
Example: customer313.
* Required for payouts

customer.country
string, optional *

Customer country code in ISO 3166-1 alpha-2 format.
Example: GB.
* Required for payouts

customer.city
string, optional *

Customer city.
A string, must not exceed 255 characters.
Example: London.
* Required for payouts

customer.state
string, optional

Region or state of the customer's billing address.
A string, must not exceed 255 characters.
Example: West Midlands

customer.zip
string, optional

Postcode of the customer's billing address.
A string,must not exceed 16 characters.
Example: B152SA

customer.street
string, optional

Street of the customer's billing address.
Example: Edgbaston

customer.first_name
string, optional *

First name of the customer.
A string, must not exceed 255 characters.
Example: John.
* Required for payouts

customer.last_name
string, optional *

Last name of the customer.
A string, must not exceed 255 characters.
Example: Johnson.
* Required for payouts

customer.day_of_birth
string, optional *

The customer's day of birth in DD-MM-YYYY format.
Example: 21-12-1989.
* Required for payouts

customer.phone
string, optional

Phone number of the customer.
A string, must be a sequence of digits, must contain between 4 and 24 characters, and can start with "+" .
Example: 79105216611 or +79105216611

customer.email
string, optional

Email of the customer.
A string, must not exceed 255 characters.
Example: test@mail.com

customer.ip_address
string, optional *

IP address of the customer.
A string, must not exceed 255 characters.
Example: 127.0.0.1.
* Required for payouts

Possible errors

The following error messages can appear after the validity check of the file uploaded to Dashboard Light has been performed.

Error message Possible reason
File is empty File is empty
Columns are duplicated Parameter has been duplicated
File does not contain required columns Required parameters are missing
Incorrect file format Extension or format of the file is incorrect
File is broken Encoding or data structure is incorrect
Payment method is not available (line# number) Specified payment method is not available
Specified project_id does not belong to specified merchant account Project identifier is incorrect
Project_id is not numeric (line# number) Project identifier is non-numeric
Project_id does not exist (line# number) Nonexistent project identifier has been specified
Payment_id is empty (line# number) Payment identifier has not been specified
Payment with payment_id already exists (line# number) Specified payment identifier has already been registered in the payment platform
Amount is empty (line# number) Payment amount has not been specified
Incorrect Amount (line# number) Incorrect payment amount value
Currency is empty (line# number) Payment currency has not been specified
Incorrect Currency (line# number) Incorrect payment currency value
Invalid date Card expiration date has not been specified or is incorrect
Card.year is in past (line# number) Expired card; expiration year is incorrect
Card.month is in past (line# number) Expired card; expiration month is incorrect